Please enable JavaScript.
Coggle requires JavaScript to display documents.
How to Structure the Dev Teams? - Coggle Diagram
How to Structure the Dev Teams?
Python Team only (3-5 devs)
What would be accomplished in 2024?
Converting existing codebase to python (this is at least 12 months of work with a team of 3 Devs)
loan management system
loan application backend
Minimal / hacky feature development (eg. BAWAG etc.)
Basically, we wouldn't really release anything in the short term
Thinking long term
eventually lower costs
tech team finally aligned with "core business competency". Data & Tech are then truly aligned - can eventually be a single team comprising of engineers + data scientists (like most data driven startups)
no longer the need for data to build random tech prototypes when the tech team is unable to fulfil the needs of the organization
Faster development
2 Dev Teams (3 + 3 devs + 1 lead)
What would be accomplished in 2024?
Stabilizing the loan application form
what would be the "New features" that we would be able to develop? This scenario makes sense only in the case that there is significantly more development that happens in 2024 as compared to a 1 dev team setup
Ales talks about stable scoring engine being the only python project - that I find unacceptable because it stems from a lack of awareness about the python setup
Thinking long term
"core competency" continues to lie halfway between data & tech / data does prototyping / tech converts it to software
misalignment stems from the fact that the python tech team is effectively working on tasks being defined by data (which is also a technical team so it is not a standard Product <> Tech dynamic) but is being managed by Ales (who doesn't yet understand the core business competency)
We need to figure out a way to solve this misalignment if we go ahead with a two team setup
Data team will need to continue to fill in gaps on projects which are not served by tech team just yet (eg. from the past - dunning setup, funnel tracking etc.)
My thoughts
Fulfin's core competency is the ability to underwrite loans using open banking data
a single team setup definitely has long term advantages but it would probably paralize us for the next 12 months, i.e. we would only be rebuilding rather than building new stuff.
We should aim for a single team eventually, but not at the cost of a 25m loan book in the next 12 months. Which probably means figuring out a way to keep Ales happy.
That being said, a 2 team structure makes sense only if we are able to build more features in the 2 team structure over the next 12 months - else, what's the point? i.e. we should be clear on the outcomes of the 2 teams
Misalignment between Data & Tech on certain aspects should be resolved -- see my comments in the 2 team structure notes. Often stems from Ales "leading" the python side of tech, but Samarth implicitly being forced to control what is being worked on. Matthew is a more natural leader of the python side of tech.
Potential Solution
Consider a 2 team structure
Team 1: Ales + Amir (Customer Facing team)
NodeJS + react
responsible for
customer
sales
marketing
Team 2: Matthew + Samarth (Data & Scoring team)
Python + react
responsible for
credit scoring
admin panels for risk & loan operations
all finance
Advantages of a 2 team structure
clear ownership
individual teams to