---
title: How a Senior Platform Engineer Successfully Unified Disparate Deployment Systems by Leading Without Formal Authority and Building Cross-Team Trust
created: 2026-03-25
updated: 2026-03-25
type: summary
tags: ["engineering", "influence", "leadership", "notes", "telegram"]
external: http://go/ui/posts/2265/
---

Here’s a strong, structured answer you can adapt:

The Answer
“Leading without authority taught me that influence isn’t about your title — it’s about whether people believe you understand the problem better than anyone else in the room, and whether they trust you to take the hard calls when things get uncomfortable.”

The situation:
At my previous company I was a senior platform engineer — no direct reports, no formal project lead title. We had a growing problem that sat awkwardly across three teams: the platform team, the backend engineering team, and the SRE team. Our internal developer platform was in a state that I’d describe as “inherited chaos” — we had five different ways to deploy a service depending on which team had built it, no standardised observability, and onboarding a new service to production took anywhere from three days to three weeks depending on who you asked. Every team knew it was broken. Nobody owned it because nobody had been told to.
I decided to own it anyway.

How I established credibility first:
The mistake I’ve seen engineers make when leading without authority is going in with a solution before they’ve earned the right to propose one. So I spent the first two weeks doing something deliberately unglamorous — I interviewed twelve engineers across the three teams and just listened. What was the most painful part of their deployment workflow? What had they already tried to fix? What did they think the root cause was?
Two things came out of those conversations that I hadn’t expected. First, the SRE team had already built a partial solution six months ago that nobody knew about. Second, the backend team wasn’t actually opposed to standardisation — they just didn’t trust that any proposed standard would account for their specific constraints. They’d been burned before by platform mandates that didn’t fit their workload.
That listening phase did two things: it gave me information I couldn’t have gotten any other way, and it built the social capital I needed to lead. By the time I proposed anything, people felt heard — which meant they were far more open to what came next.

How I structured the work:
I wrote a lightweight RFC — request for comments — not a finished design, but a problem statement, a set of principles, and three open questions I genuinely didn’t have answers to. I circulated it and asked for feedback within a week. That document became the anchor for everything that followed. It gave people something concrete to react to without feeling like a decision had already been made over their heads.
I also made one structural decision early that turned out to be critical: I asked each team to nominate one person as a “working group” member — not full time, maybe two hours a week. This meant every team had a stake in the outcome. When decisions got made, they were made with representation from everyone affected. Nobody could say “this was done to us” because their person was in the room.
When we hit genuine disagreements — and we did — I didn’t let them fester. I’d schedule a focused 45-minute call with just the two people who disagreed, no audience, and work through it. Most conflicts dissolved quickly once people weren’t performing for a group.

The hardest moment:
About six weeks in, one of the backend team leads pushed back hard on a core part of the proposed standard — the deployment manifest format. He wanted to keep their existing format, which would have meant maintaining two standards, which defeated the entire purpose. It was a tense conversation because he was technically senior to me and had strong opinions.
I didn’t escalate and I didn’t back down. Instead I asked him to walk me through his team’s specific constraints in detail — not to be polite, but because I genuinely wanted to understand whether he had a point. He did, partially. Their services had a deployment pattern that our proposed format handled awkwardly. So I spent a weekend extending the format to accommodate it natively. When I came back to him with the updated spec, he became one of the strongest advocates for the project. He just needed to see that his concern was taken seriously rather than steamrolled.

The outcome:
Four months after I started, we shipped a unified internal deployment platform covering all three teams. Service onboarding time dropped from an average of eleven days to one day. We went from five deployment mechanisms to one. New engineers joining the company now had a single piece of documentation to follow rather than tribal knowledge spread across Confluence pages and Slack history.
At the next engineering all-hands, the CTO called it out as one of the highest-leverage engineering investments of the quarter. I hadn’t asked for any recognition — what mattered to me was that three teams who had been quietly frustrated for over a year were now pulling in the same direction.

Why This Answer Works
The listening phase is the detail that makes this memorable. Most people skip straight to “here’s what I built.” Starting with two weeks of deliberate listening signals emotional intelligence and strategic patience — exactly what Canva’s leadership competency is testing.
The RFC move shows you led through transparency, not authority. You didn’t announce a solution — you invited collaboration around a problem. That’s how the best platform leaders operate.
The conflict resolution story is gold. Canva will probe for how you handle disagreement without authority. Showing that you stayed curious instead of escalating or capitulating — and then did the work to address the concern — is the most convincing leadership signal in the whole answer.
You let the outcome speak quietly. You didn’t oversell the result — eleven days to one day, five mechanisms to one. Clean numbers, no embellishment. That restraint actually makes the impact more credible.

One Sentence to Open With
“The most important thing I’ve learned about leading without authority is that you have to earn the right to propose a solution — and you earn it by understanding the problem better than anyone else, including the people who’ve been living with it longest.”
That opener signals that you lead through competence and trust rather than position — which is precisely the kind of leadership Canva values in a flat, high-autonomy engineering culture.​​​​​​​​​​​​​​​​
