From 0 to N: Lessons Learned

Lessons we learned scaling engineering team in Kreditech from 3 to 60+ people

Transcript

1. From 0 to N: Lessons Learned Alex Korotkikh @ Kreditech
2. Who we are and what we do • Kreditech = Kredi + tech • Digital banking for unbanked • Better scoring decision due to big data • Better underwriting process due to automation • 4 products + 1 upcoming • 9 countries + 2 upcoming
3. Lesson #0 • Working in startup is hard. Hard deadlines, requirements changes, lots of things to learn. If you came from huge enterprises with 6 months release cycle, mind shift is needed.
4. How did architecture changed • Founders bought a PHP app from freelancer • Team of 3 was hired to work on: • Frontend (PHP) - customer-facing products • Backend (Java) - services: payments, messaging, intgrations, data management • After 3,5 years - multiple products (PHP & NodeJS) and huge monolithic backend (Scala) • Moving towards microservices!
5. Lesson #1 • To move faster - keep it simpler. Why do you need a distributed system if a Wordpress with plugins can serve?
6. Challenges! • High development speed => high technical debt • High technical debt => low development speed • “Why we’re so unstable? Why we have so much bugs?” • End up with strong need of feature freeze, lots of painful refactorings and rewriting from scratch
7. Lesson #2 • Velocity * Quality = Constant. • Whenever product manager wants to release today - describe all pitfalls customer may find. • Whenever they plan new feature release - remind them about technical debt needed to be paid (the only question is fee amount)
8. Lesson #3 • Do less things better. If your core product on the main market performs more then perfect - only then you can think about moving further.
9. Lesson #4 • Monitoring rocks! • Business metrics - where’s a lead-cycle’s bottleneck? Is there’re a bug or just UI sucks? • System metrics - how does our database preform after TV campaign started?
10. Team structure • 3 developers = one team, easy communications • 10 developers = 2 teams (frontend + backend), each feature = dependencies • 30 people = feature-centric teams, can do any feature on their own • 60+ people = product-centric teams • Working on their own codebase • Think about internal services like it’s products, and other services/teams like they’re customers.
11. Lesson #5 • Cross-functional teams rock. Dependencies between different teams (backend/frontned) kills velocity.
12. Lesson #6 • Remote dev team is hard. When all departments sit together and only one - remotely, there’s a big gap in mood, thoughts and level of stress.
13. Lesson #7 • Managing growth is painful. Especially if you don’t have good on-boarding process and proper system documentation.
14. Thank you! • Drop me a line • twitter.com/alexkorotkikh • alexkorotkikh@kreditech.com • We are hiring! • Software engineers (Scala, Go, NodeJS) • DevOps • Product guys • And much more! https://www.kreditech.com/careers/