In technology companies, CTOs often believe that the main requirement for developers is technology expertise. That’s not quite right. We found that also having business and product knowledge helps our software engineers not only create efficient FinTech products but also spend less time on development. We started training our software engineers in finance and wealth management and saw significant changes.
Below, I’ll compare 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 is roughly as follows:
- Planning: 100 hours;
- Development: 400 hours;
- Testing/QA: 250 hours;
- UAT: 50 hours.
Production support is not considered part of an iteration; however, during the iteration we also register some extra time and effort if software engineers lack understanding of the industry.
Let’s look at each stage in detail.
When the team is planning a new iteration, the product owner (PO) describes to the team what needs to be done during the iteration. The PO might say, “We need to count the median portfolio value, count bonds, count derivatives, etc.”
If the development team has no understanding of the wealth-management industry, the engineers ask questions about portfolio value and median portfolio value, how to count bonds, the difference between bonds and derivatives, and so on.
This increases the meeting time by up to 50%. Thus, the estimated 100 hours for the planning stage turns into 150 hours.
Tasks rely on information about stocks, custodians, rebalancing, etc. Developers have a general understanding of these terms and don’t ask any questions during the planning meeting. When they start to implement the tasks, they see that they are lacking certain details. In this case, one of two options are possible:
- The developers ask questions, which means extra time spent on communication.
- The developers don’t ask questions, but complete the task in the way they think is correct. This leads to rework:
- Poor functionality needs to be fixed. For example, the developers provided search engine by securities name because they have no knowledge of ticker symbols. The functionality thus requires rework.
- Incomplete functionality needs additional work. For example, the developers aren’t aware of long and short positions and thus created functionality appropriate for long positions only. Extra time is needed to add processing of short positions.
The development time increases by up to 20%. The estimated 400 hours then becomes 480 hours.
If QA specialists lack financial knowledge, the software quality will be under threat. If they don’t spend extra time on communication and finding out details, they may overlook poor or incomplete functionality. QAs that don’t speak financial language can’t accurately describe the problem, and without knowledge of industry processes, they will not be able to suggest a better solution.
As a result, the estimated 250 hours for testing increases to 315 hours, which means that up to 25% of their time is wasted.
UAT is generally done on the client’s side by experts with considerable domain knowledge. This is why at this stage time loss only takes place due to flaws not identified earlier.
The time loss is about 10%, leading to 55 hours spent on UAT, instead of the 50 hours estimated.
Time lost during one iteration
The overall impact of a gap in the software engineering team’s financial knowledge 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%. Suppose your development team of 10 engineers costs you $50K per month. In the case of a team without domain knowledge, this amount increases to $63K.
As the software customer starts to use the system, the following issues arise due to the software engineering team’s financial knowledge gap:
- The functionality works improperly (e.g., compound interest is calculated inaccurately).
- The software is not usable (e.g., too many extra actions are required).
- The functionality doesn’t work (e.g., under particular circumstances trading cannot be executed).
The engineering team that lacks business knowledge spends about 15% more time compared to engineers with financial industry knowledge.
From iteration to iteration, software engineers who had no understanding of the industry gradually gain this knowledge. For example, if developers need to process options, but have no idea what options are, during the iteration they spend a great deal of time learning the essentials of the investment type, the possible activities of options, what information is required to allocate transactions, etc. In future iterations, they have already expanded their knowledge about options and will implement tasks with options much quicker.
In the same way, software engineers improve their grasp on other aspects of the industry. The chart below shows how the development cost changes over time for a team with comprehensive industry knowledge (green), a team without initial industry knowledge (blue), and in case the team changes and new developers need to be taught again and again (pink).
For the team without initial industry knowledge, the ramp-up time is 6 to 12 months. Here, you can see how much you will lose before your development team gains enough relevant business knowledge and can speak the same language as the product team.
To build a successful FinTech product software engineers require business knowledge—otherwise, they will waste time on miscommunication and rework. Training developers in finance and wealth management is a part of our FinTech Engineering Approach, which helps us promptly build FinTech solutions that meet clients’ needs and expectations. This approach includes all aspects of software development, including:
- Financial domain knowledge;
- Technologies and architecture;
- Team structuring;
- Processes and workflows.
Above, I have discussed how financial knowledge helps software engineers save you time and money. In subsequent articles, I’ll provide numbers on other points of the approach.