Skip to content

How to Be a Passionate CTO

Daniel Reibsamen is CTO at Guidance Residential — a provider of exclusive Muslim-tailored home financing options. With his primary task being to take the company national and digital, he dedicated 10 years to Guidance Residential and continues to push the limits. Daniel’s main goal is for the clients to get access to the technology that all the large banks have, just the way they need it.

The road to becoming a CTO

Every tech leader has their own story, and Daniel eagerly shared his.

About 15 years ago, he started as a developer: writing code and making changes to it, gathering specs, testing, and managing the database was what he enjoyed doing day-to-day. But then came the turning point.
I found that in order for me to grow, to really implement the tools that I wanted to implement, I needed a team. It was kind of just a natural progression. Do I want to just continue to sit around and do tasks every day? Or do I want to actually build tools? Do I want to shape companies and design things that thousands of users use instead of just a checkbox here or there?

At this turning point, he was offered the CTO role at Guidance Residential. Not knowing if he was fit for the job, he decided to take the risk and learned one important truth.

They say that great executives wake up every day, hoping that nobody realizes that they don’t know what they’re doing. And I don’t take that as a bad thing. What I take it as is to move forward, you have to step into these territories that you’re not familiar with.

Now he is a Zend-certified engineer, holds Oracle certification as a DBA, and builds “little startups” when he has time. And if one thing hasn’t changed over all these years, it’s Daniel’s passion for coding and love for details. When talking to the low-level developers, Daniel often surprises them with his meticulousness. That he takes as his biggest strength as a CTO.

Daniel’s dev team: The structure and how it works

If there’s one word to characterize David’s technology department, it’s “tribe.” And looking at the structure and culture David established, it’s easy to see why.

We focus on a really tight knit team and we try to focus on specific products at a time and try not to stretch ourselves too thin about what the team looks like. Our goals change so often that we don’t always finish a specific two week sprint. We might shift right in the middle, but it’s intentional, we’ve set it up that way.


The team is small and includes the following:

  • Director of engineering—keeping everyone together and on track, setting goals, and choosing a product to focus on.
  • Two lead developers—one is the lord of datatypes, securities, and storage options, while the other focuses on the company’s products (where the features can fit, how they can interact, and how they need to connect).
  • Development team— it consists of six developers.
  • Supporting staff—product support, internal support, and IT support.


Getting the best out of it

Daniel’s development team might be working with one lead developer one day and another lead developer the next, depending on what they focus on. Having a small and flexible team has the following benefits, according to Daniel:

  • You’re not reliant on one person.
  • There’s no developer who just does check boxes; instead, everyone can launch an entire dashboard for corporate use or a new tool for thousands of customers.
  • Upon building a whole new product, the developer gets credit and something concrete they can showcase as their achievement.
  • The team’s own culture creates a unique bonding. Daniel says they’ve opened a separate technology headquarters—a location dedicated just to the technology team.


Embracing challenges and facing the future

It’s much easier when you’re a smaller company because there’s a lot more trust, mainly because you don’t have enough people to do everything. So you kind of have to rely on the people that are in charge to do what they can and to do it correctly.

Management overhead

When asked about the biggest challenges, the first one Daniel mentions is a large amount of input. Reporting and requirements, the number of people submitting their requirements, and the number of people that have a say or have their opinions are one of the major hurdles for him.

In this situation, he sees his main task as ensuring all of that information can be captured and everyone has an opportunity to contribute. However, one of the things that helps reduce the amount of feedback and unnecessary discussions is working with a proof of concept. Creating one to explain what should be built and how it should work saves tons of time. The other thing is trust, and Daniel thanks for the trust the company gives him so that he can “go and build products with the team without a ton of feedback.”


Finding the right people

The other big challenge is supplementing a team with people who have enough domain knowledge.

We’ve struggled to find companies that understand specifically Fintech or even the mortgage industry, where we end up training developers more than they are producing code. And by the time the contract’s done, they walk away with all of this training experience that they got at our expense to just go do it for somebody else.

The need for developers well-versed in Fintech is particularly evident in the company context. David explains that they spend much time analyzing unique client cases and problems and focusing on those specific things. As even a little bit of friction causes a big impact on the amount of work they’re doing, it’s also a big impact on how much innovation and work they can put out. So, David chooses to seek developers that feel confident in the Fintech domain and never cease to explore it.

Eventually, such scrutiny pays off, as it ends up giving the team much more output in the long run, David says. And we couldn’t agree more—and stress more the importance of domain knowledge for a developer.

We can always get bigger. We could always spend more money. We could always, you know, deliver more features here and there, but being smaller, it forces us to focus on what’s important.

To scale or not to scale?

That depends on many things, and Guidance Residential has an interesting approach to the issue. As David says, there’s always room to do more.


You can always move faster. There’s always going to be more features, but again, you have to move at a pace that the company your clients can afford. That can consume.

What David and his team are doing is combining technology’s “ability to scale in an infinite pattern” and a specific process (mortgages, in this case) and not getting distracted with other things.

We can always get bigger. We could always spend more money. We could always, you know, deliver more features here and there, but being smaller, it forces us to focus on what’s important.

To David, scaling is not about growing a massive team to implement hundreds of new features, but it might be about finding a new area to explore. For instance, they could shift from mortgages to something else in the future, but’s will be another story to write. Or, rather, to code.

Fintech expertise + strong engineering skills = reliable solutions.
Meet our experts>>>

What it all comes down to

Passion is that indivisible particle at the heart of everything, be it Fintech or space exploration. Whether you’re looking for the right developer, choosing your next professional destination, or coming up with something great with your team, always follow your passion. That’s the main driver in Guidance Residential, and we at INSART share this motivation.

Vasyl Soloshchuk avatar
Vasyl Soloshchuk
Start sending Signals to us! Send us your expert opinions and become our Fintech Expert
Become A Member

Latest Articles