Canva’s Restructure: What Developers Can Learn

What Canva is changing

CEO Melanie Perkins cited slower growth and fragmented responsibilities. Canva’s planned changes include:

• Combining Product, Growth, and Platform into one product organization.
• Broadening some roles and consolidating overlapping responsibilities.
• Making Sydney the primary base for more product teams, with most hybrid employees expected in an office around two to three days weekly from January.

What the announcement can tell us

The 1,271 figure includes all affected employees. Canva has not published a separate layoff total and says these decisions do not reflect individual talent or contributions.

A restructuring headline cannot establish individual performance, a team’s effectiveness, or whether a new structure will succeed.

The examples below are editorial analysis, not accounts of what happened inside Canva.

Why handovers can leave a problem unresolved

Imagine customers reporting that a checkout button sometimes does nothing. The frontend developer checks the click handler, the backend developer checks the endpoint, and the infrastructure team checks server availability. Each finds that their piece works under the conditions they tested.

The failure might depend on a slow response, an expired session, or an error that never reaches the screen. These are hypothetical examples.

A handover helps when it transfers enough context to move the investigation forward. It becomes a problem when it merely moves the ticket. Someone needs to connect the evidence and verify that the customer can complete the journey.

What clear ownership looks like

Ownership means coordinating a result across the people needed to deliver it. For the checkout example, the owner could organize a reproducible test, bring the relevant specialists together, and agree on the evidence needed before closing the issue.

The developer fixing the interface might remain responsible for that code. Another person might investigate the API. Clear ownership gives their work a shared destination without requiring one person to perform every task.

A useful ticket would describe the affected journey, the known conditions, the remaining uncertainty, and the acceptance check. For example: reproduce the failure, confirm that errors appear clearly, and complete a test checkout under the original conditions.

Broader skills still need boundaries

For an individual developer, a practical response is to learn the connections around your specialty. A frontend developer can benefit from understanding HTTP responses and session handling. A backend developer can benefit from seeing how a failure is presented to the user.

This does not require mastering every layer. Start with enough knowledge to ask better questions, reproduce a problem, and recognize when another specialist is needed. Choose a recurring issue from your own work and follow it one step beyond your usual boundary.

Broader responsibility also needs support. If a role expands, discuss which priorities change, what training is available, and who can review unfamiliar work. Adding responsibilities without making room for them creates a workload problem that enthusiasm alone cannot solve.

Smaller teams still need a way to check their work

A smaller team can have a clear owner and still make a poor decision. Team size alone does not establish product quality, healthy workloads, or dependable delivery.

When considering a simpler workflow, keep the checks that protect the result: peer review for consequential changes, a realistic test environment, a release plan, and someone watching for problems afterward. Adjust the process to the change rather than removing every checkpoint in the name of speed.

For example, a developer may own a payment integration while another reviews failure handling and reconciliation. The owner keeps the work moving; the reviewer provides a second perspective. Autonomy and review can work together.

A practical next step for your team

You do not need a company-wide restructure to examine one recurring source of friction. Pick a task that repeatedly stalls between people and try three changes:

• Name an owner who can coordinate the work and raise unresolved dependencies.
• Record the context the next person needs: expected behavior, evidence, and what remains unknown.
• Agree on a completion check tied to the user’s outcome, then verify it before closing the task.

Keep the people in view

These habits can improve how a team works. They cannot guarantee job security, and a job loss should never be treated as proof that someone failed to adapt.

Canva’s announcement involves people facing difficult changes to their work and lives. The practical lesson is to make collaboration clearer while treating affected colleagues with care. Whether the restructure achieves its business goals will take time to assess.