From 0 to N: Lessons Learned

From 0 to N: Lessons Learned

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

5694167cd4e5ff648661ddf1c58be31b?s=128

Alexander Korotkikh

September 29, 2015
Tweet

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/