Scaling Engineering at kaleido.ai: From Single Team to Product and Platform Teams — Insights from “Software Engineering at kaleido.ai” by Riccardo Porrini (Canva Austria GmbH.)

Why this journey matters

In “Software Engineering at kaleido.ai,” Riccardo Porrini (Engineering Lead at kaleido.ai, Canva Austria GmbH.) walks through the team’s organizational evolution: starting with a single team, moving to specialty teams, then to product teams, and finally introducing a platform function. The catalyst is explicit: kaleido.ai’s mission is to “make Visual AI simple.” The team began with automatic background removal for photos, extended the capability to videos with a product called “Onscreen,” and launched “Designify” to create designs from photos — all powered by their AI work. After joining the Canva family, the imperative remains to sustain growth across products, users, and systems — and to shape engineering so that it fuels, rather than slows, that growth.

Listening as the DevJobs.at editorial team, we distilled the talk into a technical narrative you can apply: the problem space, the architecture of teams, the handoffs that help and hurt, and the principles that turn organizational structure into a multiplier for delivery.

The problem space: Growth, autonomy, and shared practices

Riccardo frames the challenge plainly: growth in products and users raises complexity. The engineering organization must support that growth sustainably. Practically, this implies three simultaneous goals:

• Empower teams to deliver autonomously with minimal dependencies.
• Share and evolve engineering practices across the company.
• Operate shared infrastructure in a way that increases speed, not friction.

These goals are dynamic. As headcount and product scope change, so must the structure. The talk outlines a sequence of steps that — put together — enable scale without sacrificing cohesion.

Phase 1: One engineering team — tight alignment, fast loops

The journey begins with a single, small team that includes application engineers and, crucially, machine learning engineers. Given the mission to make visual AI accessible, ML is a differentiator. Keeping ML and application work in one team ensures rapid feedback and aligned priorities.

Benefits at this stage:

• Strong alignment: A small unit can quickly converge on shared practices.
• Shared context: All disciplines work toward the same product goal with immediate feedback loops.
• Fast experimentation: Ideas can be tested without cross-team handoffs.

The limitation is inherent: this setup scales only up to a point.

The tipping point: Communication overhead around ~6–8 engineers

Riccardo gives a clear signpost: When a team grows beyond roughly six to eight engineers, communication overhead becomes a tax on delivery. Coordination gets harder, informal syncs stop scaling, and meetings multiply. That’s not a failure; it’s a structural signal to split.

Phase 2: Specialty teams — consolidate practices, mind the silos

The first split at kaleido.ai separated engineering by specialty — for example, frontend/backend application engineers in one group and machine learning engineers in another. This was the “most natural thing to do,” especially because the teams were still young and aligning on practices.

Why this helps at that moment:

• Discipline-specific excellence: Teams can focus on aligning within their craft.
• Smoother learning curves: Knowledge sharing is efficient within a specialty.

But the limits show up quickly:

• Horizontal knowledge silos: Real products need cross-functional work — frontend, backend, ML, DevOps, QA. If these are split across teams, no single team is truly autonomous.
• Coordination shifts outward: Instead of intra-team coordination, you now coordinate between teams, increasing dependencies and slowing delivery.

Specialty teams are useful for maturing engineering practices, but they cannot, on their own, sustain end-to-end product development at scale.

Phase 3: Product teams — end-to-end ownership and real autonomy

To counteract silos, kaleido.ai moved to product teams: each team takes end-to-end responsibility for its product, with as few dependencies as possible. That structural change embodies empowerment.

Why this works:

• Clear focus: Teams optimize for product outcomes rather than local (discipline-only) efficiency.
• Short value streams: Discovery, implementation, and operation live together; feedback cycles are faster.
• Ownership boosts quality: Accountability turns into proactive quality and operational stability.

However, as the number of product teams increases, a new challenge emerges: keeping shared infrastructure and engineering practices coherent.

Shared infrastructure: Essential, but don’t become a gatekeeper

At scale, organizations share production infrastructure (where systems and products are deployed) and tooling for continuous integration and deployment. If each product team optimizes locally, practices can diverge. That threatens maintainability, security, and operability. At the same time, centralizing everything risks creating bottlenecks.

Riccardo describes exactly this point: product teams are humming, but shared infrastructure and practices need clear ownership — in a way that empowers product teams rather than constraining them.

Phase 4: Platform team(s) — tools, automation, embedded practices

Enter the platform team. Its goal is not to ship end-user features; its customers are other engineers.

The platform team’s mandate:

• Own shared infrastructure and the guardrails around it.
• Build tools that empower product teams to deliver quickly and safely.
• Embed good engineering practices into those tools so that teams adopt standards by default.
• Avoid becoming a bottleneck by focusing on automation and self-service.

Riccardo’s guiding principle is explicit:

This is not just a structural change; it’s a mindset. It requires treating the platform as a product: identifying customers (engineers), understanding their constraints, and prioritizing automation over manual gates. Practices are most durable when they’re part of the tooling engineers use daily.

Current state: A scalable foundation

Kaleido’s current organization combines product teams with platform ownership. That provides a foundation for further scaling: new product teams can be added without fracturing shared practices, because the platform evolves those practices and bakes them into tools. Riccardo underscores that scaling never stops — in people, systems, and products. The chosen structure provides the building blocks to adapt while staying focused on the mission to make visual AI simple.

Transferable lessons for engineering leaders and teams

The talk offers practical, broadly applicable principles. You don’t need extra context to act on them:

1. Start small with all critical disciplines in one team to establish shared practices quickly.
2. Watch for the 6–8 engineer threshold; when crossed, coordination costs dominate. Split intentionally.
3. Use specialty teams to mature craft-specific practices, but acknowledge the risk of horizontal silos.
4. Move to product teams when end-to-end delivery slows due to cross-team dependencies.
5. Recognize the moment to introduce a platform function when shared infrastructure and practices start to diverge.
6. Build the platform as a product: define customers (engineers), prioritize automation and self-service, and embed standards in tools.
7. Avoid bottlenecks: central teams should accelerate others, not police them.
8. Guard against local optimization that fragments the ecosystem. Tools should carry the standards.
9. Scale iteratively: each stage solves a concrete problem from the previous one — don’t skip maturity steps.
10. Stay adaptive: growth keeps changing needs; structures must evolve accordingly.

Practical prompts to choose your next step

A few diagnostic questions map directly to Riccardo’s transitions:

• Team size: Are we consistently above 6–8 engineers in one team? How is communication overhead showing up?
• Dependencies: Do we routinely coordinate with multiple other teams to deliver end-to-end features?
• Practices: Are our CI/CD and operations practices diverging enough to hurt maintainability or security?
• Platform maturity: Who owns deployments, observability, and guardrails? Are core workflows self-serve?
• Bottlenecks: Where do manual gates or central approvals cause wait time? What can be automated?

Answering these will clarify whether to split a team, reorient around products, or stand up a platform capability.

Focused recommendations grounded in the talk

• Articulate the mission: kaleido.ai’s clarity — “make Visual AI simple” — guides structural decisions.
• Align teams to value streams: product teams that own the problem and solution move faster.
• Treat the platform as an enabler, not a gatekeeper: automate before you centralize control.
• Put standards into tools, not documents alone: adoption follows the path of least resistance.
• Embrace change: as Riccardo notes, scaling is continuous — across people, systems, and products.

Quotes and takeaways that stick

• “Our mission is to make Visual AI simple.”
• “When the team grows over the 6–8 engineers you start to place communication overhead.”
• “Horizontal knowledge silos” hinder end-to-end autonomy.
• “Every product team is responsible end to end … the best structure to create empowered teams.”
• “The customers of a platform team … are other engineers.”
• “The mission of the platform team is to empower … and not to be a bottleneck.”

Together, these lines trace a coherent arc: from tight collaboration to scalable autonomy — with platform teams providing the connective tissue that keeps practices and infrastructure healthy while product teams move fast.

What the talk deliberately leaves out — and why it’s useful

There are no tool or stack specifics in the talk. That’s a feature, not a bug. It highlights that structure and principles are the bigger levers. It’s less about picking a particular CI/CD suite and more about embedding practices in tools and assigning clear ownership. Without technology-specific detail, the focus remains on decisions any organization can make.

Conclusion: A robust path for scaling tech organizations

“Software Engineering at kaleido.ai” presents a clear, practical sequence: start small, firm up practices, avoid horizontal silos, empower product teams, and add a platform function to sustain growth. The current structure isn’t a finish line; it’s a set of adaptable building blocks. That posture is what makes it resilient: it supports continued growth across products, people, and systems while keeping engineering aligned with the mission of making visual AI simple.

Riccardo closes with a fitting note: kaleido.ai is hiring and continues to scale. Those interested can explore their careers page to get in touch.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  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.

  Watch now