Note: this is an automated transcription of our podcast interview. There will be some typos 🙂
Would you rather listen to the conversation? Listen to our podcast!
Hello and welcome to The Playbookify Your Business Podcast. In this podcast we interview C-level and top managers of high-performing companies, deconstruct their way of working, and dig deep into best practices of building, growing, and scaling a team. As a listener, you will learn how great companies build systems to scale and how you can do the same. And welcome the Herber de Ruijter of Nimbus, welcome Herber!
Hey, thanks for having me here. Good to be joining your new initiative. I’m pretty excited to share some insight of what I’ve done so far. A bit of a background story: I am Dutch, been around in the US for 15 years now. Currently head of engineering at Nymbus, one of the emerging and fast-growing companies in the US in the fintech space proposition to be having is that we can bring challenging neobanks to now for banks life and enable their growth. That means they might be incumbent or might be an entrance to a new niche market that they want to attack in the end. And we have capabilities that are more than just technology. It’s also taking care of compliance and risk and so on. Bring most of those companies’ life or initiatives life in a 3 to 4-month period. A bit background on the growth of Nimbus: slightly more than a year ago was 50 FTE limited amount of clients, today around 600 FTE and growing. But most importantly, IRR went double-digit more than ten times in a year. So pretty much fast growth!
Well, it is very fast growth, that must come with a lot of growth challenges. What would you say are the greatest growth challenges you guys have been seeing in the past years?
I think I’ve called that or defined that as the turnaround or the transformation to industrialize both the manufacturing and delivery of our offering, pretty much, which of course, as I said, contains software that we run, including compliance, business process outsourcing. We’ve also run, for example, the centers for those banks and so on. So it’s pretty much building repeatability in everything you’re doing. That’s one thing I call it. Like I said, industrialization of everything you’re doing. There are a lot of benefits if you make things repeatable, first of all, you get better at them. Secondly, you can operate at scale and in the future at profit. That’s not currently the main focus, maybe pretty well-financed for us. Quite important to gain market share and disrupt, I would say the status quo, which is a market that’s dominated by relatively large fintech companies like FIS and Pfizer that locked their clients into multi-six, seven-year kinds of contracts. And we kind of pretty much aggressively trying to target that market. But the overall thing challenges this is going from, let’s say, a bespoke relatively approach ranging from the way from business development sales and the delivery of the offering and running it pretty much to something that’s way more industrialized.
Right. Okay. So your company is pretty much disrupting how the traditional fintech industry has been run so far. And because of that, the company is growing a lot. But I’m assuming that must also give a lot of internal challenges in terms of scaling your team, your product, you’re offering your market.
Yes, I agree. I think it comes down to having a market strategy that clearly defines what we’re going to do and what we’re not going to do. That’s one thing. And drive pretty much revenue and focus. That means everybody is aligned ranging from sales, business development, marketing, engineering, product management, and running that same line. Of course, we trying to kind of find ways to further accelerate or solidify our positions. And that means that next to the focal areas, we always have multi two or three breakout strategies in stock. That means these are initiatives where we invest, but if they fail, we move on and pretty much pick another one or try another one in the end. It doesn’t make or break in the end if those initiatives fail us, our future, and some of that. But you need to have a certain point, a strategy to grow even faster or beyond the pace, we’re doing now. We’re operating in a market that’s really sizable. It’s a market that has a total addressable market of around 5000 financial institutions. The fintech industry is also starting to target non-financial institutions as markets, which are brands that want to offer financial products bundled with their own non-financial kind of products in the end. So the market is extremely big. So also from that perspective, next, the scaling part, as we mentioned, it’s also about not diluting ourselves too much, trying to play everywhere.
And then if you look at scaling your team, I’m assuming the company at some point in time started with a few people, and then you went to ten, and then you went to 100 and now you’re going to the next level. What were the challenges you found in scaling the team within your organization and still being able to preserve culture and growth?
Yeah, I think the major thing was that making the switch from building really bespoke solutions that are relatively close to the way how system integrators operate to just running at scale, that means you see more commonalities in the way how you work and want to operate than exceptions. If you’re mostly a bespoke company, you mostly optimize your processes on the bespoke ness of what you’re trying to deliver. So we pretty much flip the model and try to find a lot of commonalities and try to quote-unquote productize less repeatable in that part. So playbooks in our world are very, very important, particularly in a world that’s relatively complex. For example, we have clients that have already a banking charter, for example. So that means regulatory, they’re sound and solid. We only have to deliver them the technology and the business process, outsourcing and converting the banking infrastructure they currently run to. But we also have clients that have no banking charter, which is hard to get at defined into us. So we become a broker finding what we call sponsor banks for them. Right? In those stages, we are using the trust relationship that we have with other banks to bring them on board to them. And another new client framework, you can call for them for it, but that client needs to be sound and solid and going through a lot of scans and need to be compliant, which partly we take care of. So in the end, the onboarding of clients itself is a very, very complex affair that takes a lot of, I would say, expertise, subject matter experts, and people coming from various directions that we’re having. So the only way in the future to make that scalable is just to make it repeatable. That’s one thing. And secondly, I’m a big fan of Kaizen. That means always looking for where are the distractions in the process? Where do we lose too much time unnecessary, or where do we see too many deviations or exceptions? That means we have to rethink those kinds of things. So I see the way how we particularly deliver solutions to our clients, the full package, which is beyond technology, almost like a manufacturing-like process. So a lot of my inspiration comes from. Manufacturing and distribution concepts are just in general. Okay.
So, it sounds like you have like a standard playbook. This is how we deliver. But while running the playbook, you have to be able to vary in a very agile way, and change and adjust your playbook to match reality.
Totally agree. It’s always important because we mostly draw it on the horizon for a year max. Most of the time our world is changing so much and there are multiple steps to get there. It’s always the danger of when you’re building plans is that the future stages are reconsidered today. So I’m a big fan of a short cycle loop where we have a plan, we break it down into first steps where impact is high or change resistance might potentially be high, and focus on those changes itself. And also, don’t be shy to just a B test, those kinds of things internally. So experimentation, as we call it internally, as the further four steps into the change process, is relatively important to us. Complexity for us is also that for me, at least as an engineering head, our resources are at six geographies that are not relatively close to each other. So due to COVID changes, a bit harder. Mostly only on the trust side. I came in blank or a new seven months ago. Nobody knew me. Right. If you want to change quickly and fast, trust is definitely a factor. And today, operating in a remote world just meant for me that I had to work two or three times harder to gain the trust, and do way more. I would say missionary work that people see the multiple perspectives and then start to delegate the change to the various, I would say leads and enhance and managers that I have in my team.
Okay. And so would you say that you talked about change? Is that such an important topic, looking at your own customer onboarding, that change management should be an integral part of any customer onboarding playbook because you’re going to perhaps encounter resistance when you’re trying to implement it?
You change managers just in general a given we change. But also from the flip side, the regulators, because we operate in a highly regulated environment, means that all for every change needs to be balanced, captured, and so on. So on one side, I’m dealing with change to adapt to the market or the ask of the market in a domain that’s by itself changing quite heavily that fintech is, I think, one of the heaviest investment FSA kind of industries because of its potential to disrupt things on the way, how banks traditionally operate it. There’s a lot of room for disruption there, so that world is changing. At the same time, we have or I have regulators on my back every year where I have to show how I dealt with internal change in general because I’m dealing with really sensitive data, credit card data by data, and so on, and dealing with relatively. Mission-critical set of applications.
Does it mean, with all the rules and regulations that the tools you use to run your playbooks should also contain some sort of auditing capability like tracking? Like, this is our process, and this is also what we did with this customer?
Yep. Yeah. Traceability is very important. Every year or every moment that things go wrong or might go wrong or exceptions being asked for. Because of what you have to do, the regulators are very rigid. You really need to exactly follow the procedure you can request internally. I can through my department for four exceptions to many exceptions on the same topic, create a smell to the regulator. So I have to be really balancing those things out. But traceability for did I do what my policies tell me to do? And even in case of exceptions, is there enough proof point that I made a deviation or circumstance that drove us to do these kinds of things, by the way, which we had to do to cope with, for example, or to the tragedies that we are in today. I would say that also affect my teams. You have to be very strict there. Correct.
Okay. So, how do you enforce that? Is there standardized software to enforce that your team is also compliant with all these rules and regulations? Or do you have to develop that?
I try to tie the change management aspect of a process very closely to the tools that we already use. If there were, isn’t that change management yet? So for example, my team on building software, so we rely heavily on quote-unquote a ledger like JIRA. So our product teams capture requirements there. But we also have extended build capture metadata that allows us that, first of all, every change is a ticket into Europe pretty much. And secondly, there are workflows predefined and gates on how it has to go or elevate through a specific approval process or not. That sounds very bureaucratic, but the same thing applies here. If you industrialize, if you build a cadence also around change, you’re building muscle memory with people. That’s one thing. And the more you do it, the more natural it will come.Â
And so so you use JIRA more or less for project management and also to document the what? This is what we’re going to do. And then you also have the audit trail, but then the how do you is that more training in your company or do you document the how in documents and maybe in Google Docs or in presentations? Or how is the knowledge shared within your organization?
Yeah. Most traditional documents. We pretty much use the documents that we also have to capture for the regulators and to defend each year to the regulator. That’s one side. That’s a relatively traditional world, I would say. They just want to see documents. We demonstrate a correlation. Those policies, of course, do systems where the real changes happen and being captured is, by the way, not only JIRA, but JIRA is one of those systems that we’re using. We also have, for example, in our support systems, for example, requests for access to an environment or an instance of our software or what we call a specific page that we separate, for example, development access from production access. These are really strictly separate things. So there’s also very stringent, I would say, ticketing slash request forms needed that capture the request and the change and the approval for various other aspects of our business in the end. But JIRA, at least in my world, that means isn’t the software guys, which is already heavily used by management itself to capture the requirement and assign things to the backlog. We really try to get our change management processes close in line. The other part is what you mentioned is, of course, training. We have a model where we have what we called our development teams broken down into tribes. Each product group has a specific tribe. If it had broken down to squads. So the tribe leads and the squads have the obligation to be the gatekeepers for those policies and onboard new people with those policies as we operate in a relatively what I call specialist kind of organization, that means that. On one side, people got trained on the aspects that really impact their work. The second thing is, of course, also on our side, a lot of those validations, policy validations are also automated. And part, for example, of a check-in a request or a release process that we have to make sure that those things cannot go sideways. So automation is also part of more and more of the playbook.
And how long would you typically say that the onboarding takes of of a new employee? Is that weeks or months of training and onboarding and learning the processes that you have in place?
I think mostly it’s a week but it’s mostly not on the policy part that much is just Nymbus has a let’s say in-house build local platform, for example. That’s our way to bring customers relatively quickly live. But there’s a proprietary aspect to it. So you cannot get people that say, I have ten years of Nymbus local platform, so most of the time is spent on that part. But while we’re doing that for emerging policy-related things also in there related to our way of working, a way of working means how do we branch our code? How do you check in your code? How do you make your merge request and so on? Those things are part of it too.
And of course in your business because you have to a lot is documented and regulated, which is good I think in the financial world it probably should also happen in other worlds, but there’s little to no enforcement. What I found with a lot of scaling software companies is that their biggest trouble seems to be to really take the time to document and write down the process so that they can scale. Do you have any tips or suggestions for other scaling software companies on how they should go about this?
I think the separation of concern is there. So I would say you really have to allocate people, taking them out of the process, understanding the process, but taking them out to kind of, first of all, capture those things and start implementing things. We have a Nymbus around 12 or more. I say I lost a candidate, but I think at least 12 people on the compliance side that where everybody can go into if there’s also that means that if there’s also a grey area beyond the reading our current policies and that there’s a lot of grey areas you need to have people instantly available, they can ask these questions instantly and not everything can be captured in a document or create some ambiguity. Most of the policies that I’m seeing are relatively missing, open or so, but they’re really a bit more generic, I would say because it’s so hard to capture every, every use case or something that. So it’s always like common sense guidelines, directions come from the documentation, but you still need to have and the gatekeepers and internal team of almost like consultants that you can go to but separate those two things doing things on the back of. And I think that’s the problem that I’ve seen just in general, in my last four jobs working for software companies, the tendency is to if you look, for example, engineers document or creates engineering like artifacts, you’ve got documents that are only meant for engineers. And I prefer that in order to also facilitate skill and skill means on a certain point if you grow as fast as we do that it also starts with the onboarding process that you see, that onboarding of new employees becomes certainly a limitation to or you got inconsistent quality out of the people that are being on board. Or secondly, it’s to capital intensive to do that. So if you start and prepare for growth, I think capturing what shape or form of knowledge and mostly the knowledge that’s relatively static. First just given regulatory frameworks are really static, just start improving first.
Because I’ve seen a lot of SaaS scale ups that don’t even really have a formal customer onboarding process. It feels to me like a lot of them, you know, they got one customer onboarding specialist. That guy has built up a lot of knowledge and experience. It’s all in his or her head. They train the next one, they train the next one. But then, when they really have to start scaling, let’s say go from two customer onboarding people to 20, tt starts showing a lot of cracks. And if I understand correctly, your suggestion is to begin sooner than later by having a person who really documents that process and not the person who’s actually doing it?
Yeah. Because for us onboarding itself, I think it’s one of the most complex processes, by the way, that banks also deal with onboarding of clients is a complex process. Very regulatory heavy. But also in our world, a bit from a B2B perspective for us onboarding clients is equally important as I said. We might introduce them to a sponsor bank. So we want to make sure that everything is in place and we can trust the client in order to kind of onboard and connect there. But on the other hand, in our domain, we built an entire end to end full-stack banking platform where not only we, but pretty much everybody playing our space relies on a lot of third parties for a third party solution that does, for example, a know your customer check or doing, for example, authentication or do something with security or has a payment solution that we embed in our solution. So at the moment we onboard a client, we also have to provision and do something to those vendors too. We have to set up our ledgers so that we know for sure that the invoicing, including the pass-through to the third parties, is accurately registered because if you don’t do that, you lose revenue because you forgot to enforce those clients or five servers know. So it’s a relatively precise, although repeatable but precise process of following multiple workstreams.
If I understood correctly, it’s like hundreds of steps. They have to happen in a certain order and they all have to happen because if you forgot the know your customer software integration piece, then it all delays your implementation?
Correct. And you see it on every level. We really, really made an effort and I think we have a really super talented group of people that better starts from the top level. For example, our CEO with very strong opinions about how you do sales. He’s, for example, also together with our chief revenue officer, that’s one of the people that kind of rethinking how you do sales. But instead of seeing sales as a linear process that he thought that there are a couple of things you can just do in parallel and not relying on just a single person as a contributor and still doing all these kinds of things, but building a team around it. So for example, we have a sales ops organization that does a lot of things to facilitate condition guides, and steer our sales force at any stage of the cycle itself, including, you can guess it. Also the onboarding of salespeople. So one of the things that I’ve been surprised about just in the past, if you make a step from engineering to sales, it’s mostly the highest salaries are mostly paid to people if things are going well and they make their bonuses to the sales department. What I’ve always seen in the past, is these are the people that are the least trained or least supported in general, which is kind of weird, isn’t it? So for example, also if you talk about process optimization, skill, and center that having a solid engine of organizations is quite important also in sales to drive accelerated outcomes. And the numbers show you I cannot disclose what those numbers are, but I’m used to see in the similar industry contracts to signatures. That means closing contract cycles. A clause in double-digit and limits does it way, way, way in the single in the lower single digits of things which is testament to.
So this sounds like you’re I’m sort of getting to conclusions here. One is your CEO has a very strong sales playbook that he enforces to the team of a proven methodology on how to sell and what steps are involved and the knowledge and whole?
It’s going to be published, by the way, soon. He was so proud of it and he thinks it’s so disruptive. He’s going to publish that book.
And then, on the other hand, he also mentioned a sales employee onboarding playbook, which truly follows a proven process of making sure that every new sales hire is following the proven process in your sales playbook?
Yes for in the process, but also utilizing all the assets and artifacts and let’s say instruments that have been developed. So make sure that they utilize those instruments consistently or creatively in the same way possible.
That’s good. Well, my takeaway, however, has been from the session with you is to industrialize your SaaS company, think like a manufacturing plant and be agile to adjust when you see that you need to adjust based on what’s happening in your industry. Is that a fair recap of this session?
Yeah. I call Industries. It’s one of the North Star projects. How I came in. In this case, a nimbleness to turn them around. Quick from it, say a company that gets things traditionally a bit more bespoke to repeatable with relatively short turnaround cycles and trying to build scale and for the long run through scale and high profitability.
All right. Well, I’ve learned a few new things and I look forward to the book of your CEO. And thanks very much for the session.
Welcome. It’s a pleasure.
