Deciding Whether or Not to Have Engineers Who Know Finance
In FinTech, there’s a hiring conundrum: Should you hire engineers with knowledge in finance? Some articles and research studies say it really can shorten the development time; however, there are many proponents of the opposite as well: hiring strong technical specialists is costly, and it’s possible to teach engineers basic finance concepts on the go.
In this article, we’ve gathered contrary viewpoints and their arguments, as illustrated by the experience of our FinTech CTO Club members. We hope it will help you get to the bottom of this question and make better hiring decisions.
The case for domain knowledge
Anthony DiSanti, CTO of Shift Markets, says that strong experience with the concepts of financial markets is crucial for that market, something he learned when hiring people from outside of financial markets and outside of Fintech. One of their major challenges is understanding the requirements for each project.
“Obviously, there’s an error in your code if you have an order book with an inverted spread. These concepts can be very difficult for someone just entering the market to understand and often results in lost time and development effort.”
When managing product teams, seeing the big picture in the financial domain allows engineers to stay focused on building the right things and understanding customer pain points.
Also, Shift Markets have company-wide training sessions to cover topics aimed to develop a deep understanding of the financial business domain such as how an order book works; the concept of a “bid/ask spread;” and models for maker-taker trading versus an exchange product, which is what they do for crypto.
“Knowledge sharing is very important for keeping everyone productive and moving their knowledge forward. As new members join the team, we want to make sure that they’re seeing all the latest and greatest that we’re developing. And oftentimes, the newer things are deprecating older things anyway. So, the trainings keep everyone up to speed, and to a certain degree, onboard new developers as well.”
The case against domain knowledge
Ara Anjargolian, cofounder and CTO of YCharts, has another philosophy: 90% of the time engineers struggle with engineering challenges, not financial ones.
“Our preference is just to find very good engineers. We think that we can teach them the finance stuff they need.”
In the first six months, they teach engineers several topics to make sure everyone knows everything necessary to do the work as they get exposed to different areas of the system.
“We’re not big enough to have YCharts University or anything like that, but we know exactly the things that people tend not to understand, like what an index is or what its unique properties are, what data is, what risk is.”
So, Anjargolian’s philosophy claims that engineers should acquire all the knowledge they need in the natural course of their practice.
Other points of view to consider
Joseph Konrad, Head of Data Quality at AdvisorEngine, says in his article that building a culture of knowledge sharing within the company contributes to deepening team cohesion, completing projects quickly, handling a crisis or an unexpected departure well and helping people add extra skills to their resumes. For a CTO, it also can be useful for earning a positive personal reputation in an organization by sharing know-how and mentoring. It stands to reason that in a Fintech firm, technical and domain knowledge sharing should go hand in hand to provide all the benefits of this culture.
On the other hand, knowledge hoarding, which is the opposite of knowledge sharing, can seriously damage an organization’s efficiency, morale, or forward momentum, Konrad says.
Vasyl Soloshchuk, CEO of INSART, a Fintech engineering services company, found that having business and product knowledge helps software engineers not only create efficient FinTech products but also spend less time on development. He compared the time spent at each stage of iteration by developers with domain knowledge versus those without it.
Suppose that one iteration includes 800 hours of work for a team of 10 people. The distribution of time between the stages and the corresponding loss of time is as follows:
|Estimated time (h)||100||400||250||50||800|
|Actual time spent (h)||150||480||315||55||1000|
|Time loss (%)||50||20||25||10||25|
As you can see, a lack of business knowledge in the development team increases the time needed for one iteration by 25%. Also, the team having no domain knowledge would require a ramp-up time is 6 to 12 months before it gains enough relevant business knowledge to speak the same language as the product team.