Ep. 017: Bringing It Back to the ‘Why’ of Your Business | w/ Special Guest Sebastian Kline of Nelnet Community Engagement

You're listening to another episode of Open Source CXO, the podcast designed to share insights on how to excel in your business using technology, regardless of the industry. Host Robert Kehoe is a self-taught software developer who has grown to the role of CEO. Renowned for his collaborations with organizations such as Stanford University, Nelnet, and Louis Vuitton, he continually seeks new challenges to conquer in the world of tech. Joining him is Don Blackburn, a veteran COO with over 25 years of experience in cultivating diverse relationships and driving innovation in various technical projects.

Each week, they'll be sitting down with some of the nation's foremost technology leaders to develop an open source playbook, drawing from their firsthand experiences in the field. Let's talk some tech. So today we're talking to Sebastian Klein, who is vice president of engineering for Nelnet. Welcome.

Hey thanks for having me on the podcast. This is one of my first, this is my first time recording, so we'll try to keep it as conversational as we can. Absolutely. No, it's too awkward.

It'll be a piece of cake. We're just going to have a kind of a conversation. First off, I wanted to kind of talk. So you, full disclosure, you're a former client of ActiveLogic, so we've known you for a little while.

You have the distinguished honor of being our first client as a guest on our podcast. Honored. So, blessed. So I just wanted to kind of, for the viewing audience, kind of talk about Nelnet.

You started out where 3 is the local company, right? And then was purchased by Nelnet. Yeah, gosh. You know, my journey with, you know, getting into Nelnet is, it's one that started in the, you know, in the Columbus, what is it, Columbus Park area of Kansas City.

We had this tiny little office and it was just a handful of us. And we were building mobile apps for churches, schools, nonprofits, and then we had a fundraising platform as well, right? So you have a reason to organize a community of people and a cause. You want to raise money and, you know, make change in the world.

That's what we served. And so started there as the first, one of the first software engineers in the company. And then through mentorship, you know, Joe Terry, Scott Connerly, we were able to grow that engineering department and the company to the size where Nelnet was like, hey, you guys have something good going on. How about we acquire you?

There's some synergy between some other companies that we own and the company that you've built. And so, you know, it's been a long journey of evolving myself. My peers around me have evolved, you know, from just doing the work to managing the work. And it's been a fun journey.

So the ultimate success story, right? That's every startup's dream is to start up and kind of mess around, build something fun and say, hey, look, you can get acquired. You've got to have all the like terrible stories about how cramped and awful the office was. And if you look, if you go back and you talk to a lot of people who've started companies, they'll inevitably have a bathroom story to tell.

There's always the bathroom story because the office is so small. You know, right, right. And we had our fair share, you know, our problem was like hardwood floors and about a three inch gap between the bottom of the door and the floor. So it wasn't really privacy.

It was more of a, you know, just shy of an open door policy for the bathroom. That's good. And then things change drastically because comes into a picture and then all of a sudden you're right. Big time, right?

Right. How big were you guys before Nelnet approached? Gosh, you know, they approached us fairly early in my journey there. I was only a couple of months in and Nelnet was like, hey, we want to come partner with you.

And so our journey was a slow integration into the larger company. It wasn't some, I think a lot of people think of acquisitions like you walk in or you leave Friday and you're one company and you walk in the next Monday and you're something different. It's not, it's not always a fast transition. And for, for our teams, it was really an acquihire, you know, there's different reasons that companies purchase, you know, startups.

And in our case, it was more of an acquihire. They saw the talent that we already had on the team. Of course the product was good, but the real value was in the knowledge of the team and what we were doing. And so it was an opportunity to bring newer talent into the organization, foster and grow.

You know, for instance, Joe Terry, who was the CTO, when I started, he, he's transitioned over to a different part and is running an entirely different division of software. So it's, it's, they, they saw the opportunity to bring us in and cultivate us and then look for ways for us to contribute more broadly. It's a great term. Yeah.

Acquihire. I've never heard that term. Oh really? Okay.

I've never heard that. You know, yeah. I mean, it really, the only reason I came up with that is I, it was just a lot of questioning of like, what the heck did they buy us? You know, like inevitably you want to understand why are we here and why do we work together?

Cause they did keep the software though, right? They expanded it greatly. Absolutely. From my understanding that was, you know, a decent size portion.

I think Nelnet and you can explain a little bit of who Nelnet is and what they do, but I think they have a big hand in payments, like different transactional type payments or credit card processing and various things. Is that, was that, I think that was from what I understand at least, that was one of the reasons that they were interested. So is that, is that correct? Right.

So when we were early, I mentioned we did, we do fundraising. We collect payments, right? You put your credit card information into our software. We charge and collect the payment, help with bank account reconciliation for our customers.

So payments are central to our platform. And a long time ago, there was a company called PaymentSpring, which has now been evolved to Nelnet Payment Services. That company was who we chose to partner with. And that connection was made because Nelnet, even prior to the acquisition, was an early investor.

So there was already a relationship established there. And so it was like, hey, we have this company in our portfolio. How about the two of you work together? So that's how they found out about Nelnet in the first place.

Yeah, yeah. I mean, that, well, a wear through at least, you know, and so there's a facilitation of, you know, can we be invested in the company that collects the payment and invest in the company that processes it? And that's how we got started. And you know, Nelnet, I think a lot of people have misconceptions.

I mean, Nelnet's been in the news recently and not in the greatest of lights, to be honest. But that's, but Nelnet is such a large company. And it's one of those companies where unless you're involved in loans to some depth or you have a student loan through them, you're probably not going to know who they are. Right.

Right. But they're a publicly traded company. They're quite large. And so through the process of getting like, as I got integrated into the larger organization, there was a lot of learning I had to do.

And what I discovered is, you know, Nelnet, of course, does a lot of student loans. So if I wear a Nelnet t-shirt out, inevitably someone is going to come up and say, hey, hey, hey, can I talk to you? It's almost like the extended warranty thing, but maybe worse because I am honestly, you know, Nelnet is so large, they have a separate division for handling student loans and what they call their diversification side. And so that is a separate division from where I operate within.

The part that I operate within is Nelnet Business Services. And really the mission there is to look for ways to, you know, future proof the organization. You know, we're looking to grow and, you know, attract companies that have mutual interest. Right.

So they discovered Aware3 and Nelnet Payment Services. You can start to see these payment and banking adjacent businesses, how can they build on their knowledge of banking and finance and extend that into the world of software. Sure. So we're really, you know, and Nelnet Business Solutions owns more than just software.

Like there's an energy company, there's a fiber company, like there's a lot going on. Right. Nelnet is kind of a holding company. They just own all kinds of different businesses.

Right. They're invested in a lot. And I think for the future of the company, it's all about growing that part of the business and helping attract new ideas to keep, you know, keep the business growing. Sure.

And we talked a little bit in the past about the customer centric kind of approach to managing teams and things like that. And something that you had to get involved with, kind of getting your teams to think about the end client. So in your case, is the end client, you know, literally the customer or is it an internal customer? Yeah.

So our customers are all outside the company. That's what I thought. Right. Churches, schools, nonprofits.

So they're, you know, for schools, it's your admissions office, it's your, you know, school administrators. It's also, and this is the part that makes some of our software complicated. It's really, we have two groups of customers. We have the people who belong to the communities that these organizations serve, right?

Those are, you know, if you go to church, it's your church goers that download the app. If you go to school, it's the parents that use it, but also the students, you know? And then you've got another classification of users on our platform, which are, you know, the administrators, the folks who work for back office. Right.

So, and then you, you've tried to, as an IT leader in that type of an organization, tried to impress upon the development team, the developers, down to the developers and the BAs and the project managers and so forth, really what the end goal is and what the purpose is, right? Yeah. You know, and there's a lot that goes into that. I think the buzzword might be customer centric engineering teams.

We deal with it all the time. Yeah. And I think that's a really good question. Customers have no idea what they want.

Right. Or, or I think you, I think you get two flavors of this, right? Customers don't know what they want, but also engineers who are like, oh, I don't understand why I need to really know to some depth about the customer. And if I were to reframe customer centric, I think it's really just about how do you build business acumen within your teams, period.

And, and, and, you know, that takes on different forms because your sales department has to have a different level of business acumen. IT has to have a different level of business acumen. Certainly. Support, of course.

And many other departments as well. But you know, I think one of the things that we have done really well, we've always tried to stay true to this is that, you know, your job is to come in and we're all here to create value for our customers. Let's all align around that. What does that look like?

And engage in discussions around how do, what are the actions that we can take as IT leaders to drive those behaviors? And going back to the why of the business is so important. And then repeating it. You know, one of the interesting conversations you might be able to have is, you know, here's our mission, right?

And I think a lot of people are like, here's our mission, so get in line. But I think there's actually a worthwhile discussion to have at the individual level, right? Because everybody's all hands meetings and everybody's rah rah. And here's the mission.

And that's all you hear is during the all hands meeting, rah rah, here's the mission. And then you walk away and you go get lunch and it's lost. But the conversation can continue beyond the all hands meeting. And that's where really strong leadership and management comes in, is that you want to maintain a curious mindset.

Here's our mission. But Don, you know, let's sit down and dissect this. What does our mission mean to you? When you read this mission, what does this mean to you?

And do you have any objections to it? Are there any things that are conflicting for you? How can I help you overcome that? Because understanding the mission and maintaining an engaged workforce kind of go, you know, it's typically you find those go very much hand in hand.

Yeah. Even when it comes to obviously developing, understanding what it is, even to like somebody just the question is, yeah, can you piece off the task, throw it to a developer without them understanding the mission? Do you think that would be as successful as then understanding the full mission in general? No, no, I don't think you can.

Depends on your background and some of the experiences that you've had. But I've seen where even leaders, especially outside of engineering, come in and go, oh, they write code. That's what they do. They're code monkeys.

And I actually, oh, that's a revolting term for me. That's not a good one. I hate that. Yeah.

Because really what we're trying to do is build an organization where you can be a solutioner for the business and that it's everybody's job to solve the business problem. So the leadership team, you know, we've got to get together and really clearly articulate what are the business problems we're trying to solve and frame them in business terms. Sure. And you guys do that through your all hands?

Is that the, you know, is that your opportunity to present that? There's all hands. That's an opportunity to get everybody together and continually iterate on, hey, here's what we're doing. What's important?

What are some other, what's some additional context we need to bring into the conversation? Something we did early on that was really helpful. We started a meeting, it was once a quarter, called All the Fields. All the Fields.

I love the title. I don't like calling meetings. All the Fields. Weekly touch base or.

Yeah. Yeah. Like as soon as there's a corporatism, we're going to be like, oh, I'm going to be a corporatist, or, yeah, like you got to get it something as soon as there's a corporatism. Yeah.

Sort of check out mentally. Oh yeah. You know, you're like, oh, can't wait for this. All hands meeting.

Right. All the fields. No, I'm pissed off about this. I'm going to go and meet.

I'm just going to do it all. Here's the thing. It's not a bad idea. No, I love it.

Was we were able to bring together the sales team and the customer support team and the prompt to them, and this was engineering initiated, but executed by the sales and support teams is, hey, once a quarter we want to get together. We want to give you a platform to talk about who are the new customers. And I'm not talking here are their names and here's their ID in the database. Right.

No, it's not that. I want to see their face. I want to know what their mission and what their cause is. What is it that they do that my engineering teams support?

What are we moving forward in the world so that when they go to so when my engineering teams go to Thanksgiving and someone says, how is work going, they can have on hand a better answer than, well, you know, we've been writing automated tests. No, no, no. They can talk about the, well, we've been building a new feature, which has allowed these customers to be on boarded and these are the purposes that they are. Right.

That they're moving forward in the world with. Right. So that's, you know, it's recognizing that what we do is not write code. We provide we are we are conveyor, you know, of value.

We take the problem or the new idea and we turn it into real value. And it's easy to forget about, you know, it's easy to forget how to how to express what the value was created by the engineers. We solve problems. That's what we do.

And honestly, that's I think a lot of developers, development companies, even like ours, they miss the ball there because they're so they're so fixated on this idea of just getting the product done to client specifications. And again, I don't think a lot of clients understand what they really want or what they need. Well, it's a balancing act because you want them to focus on the task. Right.

But but also we're getting a big picture and problems. Right. And, you know, and I think that's a huge part of development. We're not there just to write code or solve issues.

And our case is much smaller than yours. I mean, at one point you had how many developers on that? The project we were involved in was team size of 80. All right.

So 80 developers you run. All of them, you have to get down to that level. That is a good question. How and how do you get that much feedback from that big of a team?

Do you know how do you do realistically consider everybody's input? And if so, how would you how would you manage that? But let me let me put a pin on that. I want to come back to that for just in just a second.

But I before I forget it, I recognized I started to talk about the format of all the fields and left off a crucial part. No, no, no, they can switch it around. Let's hold on to this. So in addition to who are the new customers, what are their what are the questions?

Yeah. What do they look like? What's their face look like? Oh, OK.

I don't want to see their logo. That's boring. I want I want Phyllis that is the director of whatever. Yeah, I want to see that.

But there's another counterbalance that's that's that's the the yay feel. So if we're talking about all the fields, it's also important to understand what were the problems, what were the bugs that were important that we solved this quarter? What were the most noteworthy bugs for customer success and support? Sure.

When they think about these were the largest impacting things, they can talk about it in a way that is, you know, not not there to say, well, look at these bugs. Why do we have bugs? No, they say, hey, we have bugs and look at how you these are the ones that we really cared about. Thank you for resolving.

And if they're and by that point, we've already had things like retros. And so all the all the hashing out of how to improve has been talked about. Right. And then again, you know, the sales the sales team gets a platform as well.

Right. They can talk about here are why these customers purchased. And if you think about customers purchasing, there's also customers exiting. Yeah.

And that's a very real problem. You know, so how do we communicate? I mean, that was part of the impetus was we did have a retention problem at one point. We struggled with we were we were in a transitionary period and we were kind of losing sight of what mattered and we needed to recenter.

And so that was the impetus for all the fields at the time was, hey, we need to like I said, it is everyone's job to solve the business problems. The business problem is we have a customer retention issue that impacts revenue and growth and that that that that. Right. So let's talk about why customers are purchasing.

But let's also talk about why they're leaving. And it really framed the dichotomy between the two. Sure. Because you could say, well, you know, it's maybe maybe those customers are.

When you evolve a product, sometimes you're going to have customers say, well, it's no longer fits what I needed, but it still works for the 80 percent. Right. You know, some nutrition is normal, but, you know, really diving into what are those pain points and getting an opportunity to put that in front of the engineering teams, because it could just be something as simple as, you know, the phrasing is, well, you know, took a while to load this report. And so I had to hire an additional person in order to be able to run those reports.

It took a lot of time. And ultimately, we just we've got to move on to perform a platform. OK, good to know. Yeah, to know.

And think about that from, you know, from an engineering perspective, what's the problem to solve? Yeah. Speed. Sure.

Right. So it puts and it's not let's work one ticket or an epic to improve the speed. It is consistent behavior. It's consistent progress against that challenge when you're building new features, when you're fixing bugs, you can spot these things that are important.

Yeah, that's interesting. Yeah, it's just the constant communication down to, you know, I'm sure the leads get that or the managers, the directors get it. But then communicating it all the way down, all the way down through the engineering team and the and the QA and the BAs and everybody else, it just kind of that's that's got to be a challenge. Yeah.

Do you guys take it that far? You guys go all the way down the chain and make sure everybody as much as we can. I'm not going to tell you we're perfect there. Right there.

I'll tell you when you get. I'm just communication within a within a large organization can be a real challenge. Oh, I think a lot of people will relate to this. But I I had a situation six months ago where and this is the worst feeling, in my opinion.

I just it made my skin crawl that it happened, but there was communication that made it to one part of the organization, but didn't make it to the other part. So then you've got these these cross functional teams and the communication went horizontally. And so individual contributors on some of these other teams where they did not hear the news, individual contributors heard about it out of management. And that only took one time to happen for me to go go find a trash can and puke.

It made me so uncomfortable. And then, you know, and then reconcile that. Right. So like that, it's not a it's you're not going to be perfect.

Yeah. Or I think there's a when leaders talk about communication, it can be real easy to put them on a pedestal and expect perfection. I'll tell you one of the evolutions that I've had to go through. I naturally have got a strong inner critic.

Yeah. That strong self of a strong sense of inner criticism and learning to be kind to yourself has been one of the one of the things I've had to do. And I think a lot of us can benefit from, you know, we're going to make a mistake. That's fine.

How do we how do we be kind to ourselves and recognize what was the problem? Make the change and then move forward without without holding it over your own head. Right. Right.

So the the one thing the other thing I wanted to bring up to is the not just the large team and communicating the customer centric and all the information that's necessary to really have a purpose and a drive. But then you've got the added challenge of having offshore teams, too. Yes. How did that I know it didn't start with a where three right now.

That was part of the NELNET transition. Then all of a sudden, offshore teams, development teams were introduced to the to the project. Did that extend to them to do you try to get the offshore teams to still share in the vision of what the customer experiences and so forth? Or is it more you know, they just do a job.

How do you do you keep a team that's overseas engaged in the same way that you do your U.S.? Right. There are some.

So I've had to manage international teams at this point for a couple of years. And one of the one of the questions I think is really important to ask yourself is what is the role? What do you need them to do? And you know, I think a very responsible use of overseas talent is something akin to can we solve the problem where we need 24 hour support?

OK, very good use. Sure. And but what has to follow is equal amounts of accountability. And let me actually sidestep the word accountability, because I think that is another overused phrase in the market right now.

How do you how do you hold them to the same level of standard that you do your U.S. teams? Because I think there's a tendency to not.

Sure. You know, I think the practicality is, is that workers that aren't U.S. based tend to be lower cost.

So then psychologically, Don, what does lower cost signify? We're probably lower quality or lower production. Right. Lower, lower value.

You know, it's like. So then you go, OK, well, you know, I'm just I'm paying less money. So like I'm going to like spike less. But that creates a really weird and very bad dynamic on your team.

You want to talk about a cultural problem that's about to erupt is. So are you saying that your expectations of a lesser value entity within the company compared to you have two developers, one one here in the U.S., one offshore.

But your expectations are lower over here because you're not paying as much as that. Is that what we're saying? Well, not saying that or advocating for it, but that can happen. Gotcha.

And you were trying to set the keep about a level. It's yeah, it's a matter of here. We're going to, you know, and honestly, if I'm being truthful, I think there is a problem in the market where we are or seeing companies capitalize on lower cost development efforts in a way that personally I'm kind of opposed to. Right.

You know, it's the idea of, well, we can save money by using cheaper labor. Mm hmm. Philosophically, fundamentally, I just find that very gross. I think a very responsible, a more responsible way to do that would be to evaluate the cost of living, pay, pay a more commiserate salary relative to their cost of living as with the United States and even consider normalizing those salaries.

If you're going to hold folks to the same level of expert, same expectations, you need to make sure that your. Your compensation is fair. You know, you want to talk about equity for a minute. And I'm not not the concept of equity in the company, but pay equity.

It's I perform at the same level as my peer and we are paid similar. Yeah, similar. Right. Right.

Right. Kind of run into a pay equity problem there. But I'm rewinding out of that rabbit hole. It is a rabbit hole.

I've been down several times myself. Yeah. Rewinding out of that. We may.

Our initial use of some some folks in the Philippines were to have them focused on delivering against technical debts that we had accrued. We had to build a lot of features and you'll also help us with that. That was pretty. Was it?

We were. We were hitting it hard there for a while, dude. Yeah, it was like 44 features in two and a half years. Yeah, it was a lot from scratch, not like tiny enhancements.

This concept does not exist. Let's build it. Right. Right.

Kind of features. And so we had a lot of development going on. And as with anything, you know, the word technical debt shows up because you're moving fast and we're not breaking things, but we might be putting band-aids on it. We've got to pay down that debt eventually.

And so they were a strategic arm for us for for quite a few years. More recently, we're moving them into a, you know, we're trying to normalize those expectations. But for the purposes of technical debt, that was a more clean cut. We've defined the box and we've said operate within this box.

We will tee up the work. We need you to execute. Your role is execution. And a lot of the initiatives were focused on technical problems, not necessarily customer facing problems.

OK. But it didn't deter us from authoring what we call technical notes and technical notes, of course, describe some of the architecture, but it can also provide the why. Why is this even here? Why are we removing this technical debt?

And I think that continuing to educate the why behind the work, regardless of whether it's customer impacting or not, will continue to drive engagement. And at the end of the day, you can't make somebody be engaged. I mean, right. I can't imagine.

But, you know, something that came to mind while we were talking, you all serve many customers. How do you approach, you know, educating your teams on the problems that need solving? What is your approach to our people allowed to ask us questions? Yeah.

I don't think that's what this is for. Robert, I hear you there. I'm going to break the rules. I'm a former client for, you know, there's a lot of.

It's a great question. And it's something actually we've thought about a whole lot lately. We've been getting into what we're calling, you know, more of a consulting type, you know, arm of the company where we'll have not just, you know, me, which I've been an engineer for over 20 years myself, but our directors and anybody who's sort of client interfacing with us, we take much more of an effort to understand the business challenges, the problems, talking to all the stakeholders.

And then we, you know, our teams are pretty much small. They're not 80 people. They're like two or three people. Correct.

And sometimes they can be a little bigger. So it's a lot easier to get that information across. But we also have taken steps to do additional sorts of, you know, training for our leads to even be a type training so they can go in and truly understand. It's truly what we've been facing for the last at least six months where, you know, we've had, I can name a few clients right now here in Kansas City alone that they've come to us to help solve the problem.

We'll go in and build the product, come up with a solution and show it to them. They have devs, they have technical team, but they will allow us to sort of solve the problem using software, present it to them. And they're like, yeah, let's do that. And then, you know, we've built our own sort of project and now we're working on it.

So we do something a lot, you know, very similar. We've, you know, when I started the company, it was a learning process for sure. So you guys were a big part of our growth as well. So we had the ability to kind of learn and understand.

And I'm not going to lie, we've bought a lot of concepts from our development process because of you guys. So you know, we've learned a lot. But one of those things, especially lately, has been exactly what you were referring to. So smaller teams are a lot easier for us to do.

Absolutely. Yes, because you have those weekly meetings with the team. Well, the dev leads or the software leads are going to have daily meetings with the team, right? And it's pretty easy to convey, hey, the client's not happy here.

Or the client, this is really important because this is what the client's trying to do with it or something. It's much easier to convey that why. Your distance between the customer and the developer is much shorter. Right.

Exactly. And I think that's a very real problem that larger companies have. You know, you've got to focus on why we're here and hold those conversations. But it is difficult because even our devs don't have direct conversations with the client.

Right? Our devs are just hearing it secondhand, same as your dev team. They don't get to meet the clients. Secondhand might even be.

But it's not so far down the chain. It's not. But I really like your idea of, hey, show them a picture. Give them the whole scenario.

Give them the whole backstory so that going into a project, they really get it. Organizations are nameless, faceless. Yeah. Yeah.

And that's a problem. Yeah. You know, if you put a photo of somebody and you say, hey, do you care about this logo? Yeah.

Exactly. I'd be like, what's the logo? I don't know. But even the reverse is the same.

Our clients sometimes see us, you know, if they only deal with one particular person, it's really hard to see us as real people. It's like, why does that bug exist? This shouldn't exist. And it's like, OK, we're people, you know.

So we'll do what we can. But I think that problem is reversed. What you said were people, right? And that's what it's all about.

It is the people in the organization. It's creating the environment for these people to have good information about the customer, about their performance, about their career, and how they can make a difference in the world. Right. And it's all about people.

And so the same is true when you're looking at customers. It's all about the who, not the what. Yeah. It's interesting that we're, of course, a company that's very customer-facing, because like you said, that's our whole business, right?

We've got a number of customers that we service at any given time. But it's interesting to see that even in the giant corporations, like an L-net, right? It's still customer service. It all comes down to customers regardless, right?

Right. Well, and I think one clarification I want to make earlier is like through the acquisition of Aware3 and the Nelnet, some of our scope grew. And really, what I've been fortunate enough to have is a focus on, hey, you're the VP of engineering at Nelnet Community Engagement. And that is a nice, focused area.

Because I've got a boss above me and then the CTO. Okay. Right? So I've got a senior VP and then the CTO.

And I tell you that even just going one layer up, I cannot imagine my boss, Brittany's job, and how difficult, because she's across multiple organizations, not just one large organization. So she's got multiple of me reporting up through her, and you talk about a difficulty distilling and communicating information. I think she does it in such a beautiful way. It's very thoughtful.

And I've had to rethink even some of my own ways of capturing conversations and organizing them because it's just like when there was one part of the organization that didn't hear the news. It's those little details, especially at higher levels of leadership communication, that is a large... Holding conversations is a large part of your output. Yeah, this is great though, man.

I think there's a lot of good information in this.