Engineering skalieren bei kaleido.ai: Vom Ein-Team-Start zu Produkt- und Plattformteams — Einblicke aus „Software Engineering at kaleido.ai“ von Riccardo Porrini (Canva Austria GmbH.)

Kontext: Warum diese Reise zählt

In „Software Engineering at kaleido.ai“ stellt Riccardo Porrini (Engineering Lead bei kaleido.ai, Canva Austria GmbH.) die Entwicklung der Engineering-Organisation vor: von einem kleinen Team hin zu Produktteams und schließlich einer Plattformfunktion. Die Triebfeder: ein klar formulierter Auftrag — „make Visual AI simple.“ Kaleido begann mit automatischer Hintergrundentfernung für Fotos, übertrug die Aufgabe auf Videos mit einem Produkt namens „Onscreen“ und schuf mit „Designify“ ein Werkzeug, das Designs aus Fotos generiert. Nach dem Beitritt zur Canva-Familie bleibt der Anspruch, Wachstum in Produkt, Nutzerbasis und Systemen nachhaltig zu tragen — und die Technikorganisation so aufzustellen, dass sie dieses Wachstum beschleunigt, nicht bremst.

Als Redaktion von DevJobs.at haben wir dem Vortrag zugehört. Was folgt, ist eine strukturierte Aufarbeitung der gezeigten Organisationsarchitektur, der Motive hinter jedem Schritt sowie der übertragbaren Lehren für Engineering-Teams, die ähnliche Skalierungsphasen durchlaufen.

Der Problemraum: Wachstum, Autonomie und gemeinsame Standards

Riccardo rahmt die Herausforderung eindeutig: Mehr Produkte und mehr Nutzer bedeuten mehr Komplexität — und damit mehr Bedarf an klarer Zuständigkeit, effizienter Zusammenarbeit und belastbaren Praktiken. Das Ziel war und ist, die Organisation so zu formen, dass Teams:

• autonom, schnell und mit minimalen Abhängigkeiten liefern können,
• gemeinsame Engineering-Praktiken teilen und weiterentwickeln,
• und die gemeinsame Infrastruktur stabil betreiben, ohne Engpässe zu erzeugen.

Diese Ziele sind nicht statisch. Sie ändern sich mit der Teamgröße, der Produktbreite und dem Reifegrad der Organisation. Der Vortrag beschreibt eine Abfolge sinnvoller Schritte, die in Summe eine skalierbare Struktur ergeben.

Phase 1: Ein einziges Engineering-Team — schnell, nah, ausgerichtet

Die Reise startete mit einem kleinen, einzelnen Team. Dieses vereinte Anwendungsentwickler:innen (Backend/Frontend) und — besonders wichtig — Machine-Learning-Ingenieur:innen. Angesichts der Mission, Visual-AI-Fähigkeiten zu liefern, war ML von Anfang an ein Differenzierungsmerkmal. Entsprechend betont Riccardo die Bedeutung, ML-Kompetenz eng mit Produktentwicklung zu verzahnen.

Vorteile dieser Phase:

• Hohe Ausrichtung: In einem kleinen Team sind Entscheidungswege kurz und gemeinsame Praktiken leicht zu etablieren.
• Gemeinsamer Kontext: Alle Disziplinen arbeiten zusammen an einem Ziel; Feedback und Lernschleifen sind unmittelbar.
• Schnelles Ausprobieren: Hypothesen lassen sich ohne Übergaben testen.

Aber: Dieses Setup ist an eine Teamgröße gekoppelt. Sobald das Team wächst, kippt die Balance zwischen Abstimmung und Output.

Der Kipppunkt: Kommunikationsaufwand ab ~6–8 Personen

Riccardo nennt eine Faustregel: Zwischen sechs und acht Entwickler:innen steigt der Kommunikationsaufwand so stark, dass Koordination unverhältnismäßig wird. Ab da fragmentiert Arbeit häufiger, informelle Synchronisation reicht nicht mehr, und Meetings gewinnen die Oberhand. Dieser Punkt ist kein Versagen, sondern ein strukturelles Signal: Es ist Zeit zu teilen.

Phase 2: Spezialisierungsteams — Praktiken festigen, Silos vermeiden

Der erste Skalierungsschritt führte zu getrennten Spezialitätsteams: beispielsweise Frontend/Backend auf der einen Seite und Machine Learning auf der anderen. Das war „der natürlichste Schritt“, so Riccardo. Der Grund: Das Team war jung; gemeinsame Praktiken mussten sich noch setzen. Innerhalb von Disziplinen gelingt das leichter.

Stärken dieses Schritts:

• Disziplinspezifische Exzellenz: Gemeinsame Standards lassen sich gezielt entwickeln.
• Lernkurven abflachen: Wissensaustausch innerhalb der Spezialisierung ist effizient.

Grenzen tauchen jedoch schnell auf:

• Horizontale Wissenssilos: End-to-End-Produkte benötigen Frontend, Backend, ML, DevOps, QA. Trennen wir diese Kompetenzen in Teams, erhöht sich die Abhängigkeit zwischen Teams.
• Koordinationslast verschiebt sich: Statt innerhalb eines Teams wird nun zwischen Teams koordiniert. Das kann Autonomie und Geschwindigkeit mindern.

Kurz: Spezialitätsteams helfen beim Aufbau solider Praktiken, reichen aber allein nicht aus, um Produktentwicklung end-to-end eigenständig zu betreiben.

Phase 3: Produktteams — Ende-zu-Ende-Verantwortung und echte Autonomie

Die Antwort auf Silos: Produktteams. Kaleido gruppierte Kompetenzen so, dass ein Team „Ende-zu-Ende“ für ein Produkt verantwortlich ist — mit möglichst wenigen Abhängigkeiten. Damit werden Teams „empowered“: Sie besitzen Problem und Lösung, entscheiden lokal, und liefern eigenständig.

Warum dieser Schritt wirkt:

• Klarer Schwerpunkt: Teams optimieren für ihr Produkt und Ziel, statt für disziplinäre Optimierung.
• Kurze Wertströme: Discovery, Implementierung und Betrieb liegen zusammen; Feedback gelangt schneller zurück ins Team.
• Verantwortung fördert Qualität: Ownership übersetzt sich in proaktive Qualitätssicherung und stabilere Betriebsabläufe.

Doch mit wachsender Zahl an Produktteams entsteht ein neues Spannungsfeld: Wie bleiben gemeinsame Infrastruktur und Praktiken kohärent?

Gemeinsame Infrastruktur: Notwendig, aber ohne Engpass

Ab einer gewissen Größe teilt eine Organisation Produktionsinfrastruktur (Deployments, Services, Observability), CI/CD-Werkzeuge und Sicherheitsstandards. Wenn jedes Produktteam lokal optimiert, divergieren Praktiken — das kann die Wartbarkeit und Sicherheit gefährden. Gleichzeitig dürfen zentrale Funktionen die Produktteams nicht ausbremsen.

Riccardo beschreibt exakt diesen Moment: Produktteams funktionieren, doch geteilte Infrastruktur und Praktiken brauchen klare Verantwortung — und eine Form, die befähigt statt blockiert.

Phase 4: Plattformteam(s) — Werkzeuge, Automatisierung, eingebettete Praktiken

Der nächste Skalierungsschritt ist ein Plattformteam (oder mehrere). Dessen Rolle ist grundlegend anders: Die „Kund:innen“ des Plattformteams sind nicht Endnutzer, sondern die Ingenieur:innen in den Produktteams.

Auftrag des Plattformteams:

• Verantwortung für gemeinsame Infrastruktur übernehmen.
• Werkzeuge bauen, die Produktteams befähigen, schnell und sicher zu liefern.
• Gute Engineering-Praktiken in diese Werkzeuge einbetten, sodass Standards automatisch mitgenutzt werden.
• Engpässe vermeiden — durch Automatisierung, Self-Service und klare Ownership.

Riccardos zentrale Leitplanke:

Das ist mehr als ein organisatorischer Schritt; es ist eine Haltung. Sie übersetzt sich in Produktdenken für interne Plattformen: Wer ist der Kunde? Welches Problem lösen wir? Welche Automatisierung reduziert Übergaben und Wartezeiten? Wie können wir Praktiken so in Tools gießen, dass sie reibungslos akzeptiert werden?

Der aktuelle Stand: Ein skalierbares Fundament

Kaleidos heutiges Setup kombiniert Produktteams mit Plattformfunktion. Damit existiert eine Architektur, die Wachstum ermöglicht: Neue Produktteams können entstehen, ohne dass Infrastruktur und Praktiken auseinanderlaufen; die Plattform sorgt für gemeinsame Leitplanken. Gleichzeitig bleibt die Organisation lernfähig: Riccardo betont, dass Skalierung nie „fertig“ ist — weder in Menschen noch in Systemen. Die gewählte Struktur bietet die Bausteine, um sich weiter anzupassen und die Mission — Visual AI zu vereinfachen — voranzutreiben.

Übertragbare Lehren für Engineering-Organisationen

Aus dem Vortrag lassen sich klare, praxisnahe Prinzipien extrahieren. Sie lassen sich ohne zusätzliche Kontextannahmen direkt anwenden:

1. Beginne klein, mit allen benötigten Disziplinen in einem Team. Das fördert gemeinsame Praktiken und schnellen Wissenstransfer.
2. Achte auf den Kipppunkt von 6–8 Personen. Wächst das Team darüber, steigt der Kommunikationsaufwand unverhältnismäßig.
3. Nutze Spezialitätsteams, um Praktiken zu festigen — aber erkenne ihre Grenzen (horizontale Silos, fehlende End-to-End-Autonomie).
4. Stelle auf Produktteams um, wenn End-to-End-Geschwindigkeit leidet. Gib Ownership, minimiere Abhängigkeiten.
5. Erkenne den Moment für eine Plattformfunktion. Wenn gemeinsame Infrastruktur und Praktiken divergieren, braucht es klare Ownership.
6. Baue Plattform als Produkt. Definiere Kund:innen (Produktteams), fokussiere auf Automatisierung, Self-Service und eingebettete Standards.
7. Vermeide Bottlenecks. Jede zentrale Funktion muss so gestaltet sein, dass sie nicht bremst, sondern beschleunigt.
8. Lasse lokale Optimierung nicht zur Fragmentierung werden. Gemeinsame Praktiken gehören in Tools — nicht nur in Dokumente.
9. Skaliere Strukturen iterativ. Jede Phase löst ein reales Problem der vorigen; überspringe keine Reifestufen.
10. Bleibe adaptiv. Wachstum verändert Bedürfnisse. Eine gute Struktur ist anpassungsfähig, nicht statisch.

Praktische Umsetzung: Fragen, die den nächsten Schritt klären

Einige Fragen helfen, die eigene Situation klar zu sehen und den passenden Schritt aus Riccardos Sequenz abzuleiten:

• Teamgröße: Liegen wir konstant über 6–8 Entwickler:innen in einem Team? Wie äußert sich Kommunikations-Overhead aktuell?
• Abhängigkeiten: Braucht unser Produktteam regelmäßig Koordination mit zwei oder mehr anderen Teams, um Features Ende-zu-Ende zu liefern?
• Praktiken: Divergieren unsere CI/CD- oder Betriebspraktiken von Team zu Team so stark, dass gemeinsame Sicherheit oder Wartbarkeit leidet?
• Plattform-Reife: Haben wir klare Ownership für Deployments, Observability, Security-Guardrails? Sind Werkzeuge als Self-Service nutzbar?
• Bottlenecks: Wo entstehen Wartezeiten durch zentrale Freigaben oder manuelle Prozesse? Was lässt sich automatisieren?

Diese Fragen entsprechen genau den Übergängen, die Riccardo beschreibt: vom Monoteam zu Spezialitätsteams, weiter zu Produktteams und ergänzt um eine Plattformfunktion.

Fokussierte Empfehlungen, die aus dem Vortrag folgen

• Formuliere die Mission klar. Bei kaleido.ai ist sie explizit: „make Visual AI simple.“ Das erleichtert Entscheidungen zur Struktur.
• Richte Teams entlang von Wertströmen aus. Produktteams besitzen Problem und Lösung gemeinsam — das beschleunigt Lernen und Lieferung.
• Behandle Plattformarbeit als Enabler, nicht als Gatekeeper. Automatisiere, bevor du manuell steuerst.
• Embedde Standards in Tools. „Gute Praktiken“ werden nachhaltig, wenn sie im Pfad des täglichen Arbeitens liegen.
• Akzeptiere Veränderung. Riccardo unterstreicht, dass Skalierung andauert — in Menschen, Systemen und Produkten.

Zitate und Kernaussagen, die haften bleiben

• „Unsere Mission ist, Visual AI einfach zu machen.“
• „Wenn das Team über 6–8 Ingenieur:innen hinauswächst, beginnt der Kommunikations-Overhead spürbar zu steigen.“
• „Horizontale Wissenssilos“ erschweren End-to-End-Produktentwicklung.
• „Jedes Produktteam ist End-to-End für sein Produkt verantwortlich … die beste Struktur, um Teams zu befähigen.“
• „Die Kunden eines Plattformteams sind … andere Ingenieur:innen.“
• „Die Mission des Plattformteams ist … zu befähigen und kein Bottleneck zu sein.“

Diese Aussagen verdichten die Logik hinter jedem Organisationsschritt. Sie zeigen eine klare Linie: von unmittelbarer Zusammenarbeit zu skalierbarer Autonomie — mit einer Plattform als verbindendem Gewebe.

Was der Vortrag nicht tut — und warum das wichtig ist

Der Vortrag verzichtet bewusst auf Tool- oder Stack-Details. Das unterstreicht, dass Struktur und Prinzipien der größere Hebel sind. Es geht nicht darum, ein bestimmtes CI/CD-Tool zu wählen, sondern darum, Praktiken in Werkzeuge zu gießen und Verantwortung klar zuzuordnen. Wo konkrete Technologien fehlen, bleibt der Fokus auf den Entscheidungen, die jedes Team — unabhängig vom Stack — treffen kann.

Fazit: Ein robuster Pfad für wachsende Tech-Organisationen

„Software Engineering at kaleido.ai“ liefert einen nüchternen, übertragbaren Plan: klein starten, Praktiken festigen, Silos auflösen, Produktteams befähigen, Plattform aufbauen — und alles darauf ausrichten, die Mission zu erfüllen. Kaleidos Struktur ist nicht als Endzustand gemeint, sondern als anpassungsfähiges System. Genau diese Haltung macht sie belastbar: Sie unterstützt weiteres Wachstum in Produkten, Menschen und Systemen — und hält Engineering nah am Ziel, Visual AI für alle einfacher zu machen.

Riccardo schließt mit einem Hinweis, der zur gelebten Skalierung passt: Kaleido wächst weiter und stellt ein. Wer tiefer einsteigen will, findet auf der Karriereseite den Weg zur Kontaktaufnahme.

• 

  

  Integrating Lorem Picsum into Canva

  Andreas Braumann von Kaleido demonstriert in seinem devjobs.at TechTalk in einer Live Coding Session, wie man das Tool Lorem Picsum als eine Content Extension in Canva integriert.

  Jetzt ansehen
• 

  

  Multiplatform Strategy for the remove.bg Apps

  Andreas Braumann von Kaleido untersucht in seinem devjobs.at TechTalk die Vor- und Nachteile von Flutter und wie man damit alle remove.bg Apps in einer einheitlichen Technologie haben könnte.

  Jetzt ansehen
• 

  

  DALL·E 2: Image generation with visual AI

  David Estévez von kaleido spricht in seinem devjobs.at TechTalk über die Funktionsprinzipien von Visual AIs – und welche neuen Möglichkeiten immer leistungstärkere Tools mit sich bringen.

  Jetzt ansehen
• 

  

  Visual AI Made Simple

  René Koller von kaleido erläutert in seinem devjobs.at TechTalk, wie das Devteam das Konzept von MVC auf MVVC erweitert hat und wie es zum Einsatz kommt.

  Jetzt ansehen