Free — no signup required

Introduction: Authority vs. Influence

2 min read

The Platform Engineer's Dilemma

As a Platform Engineer, you carry a significant responsibility: improving how hundreds or thousands of developers build and ship software. You are building the foundation everyone else stands on. But you almost certainly lack the formal authority to make anyone use what you build.

You are not the manager of those application developers. You cannot hire them, fire them, or mandate that they adopt your new deployment tool. If you walk into a team meeting and say, "By next month, you must migrate to our new Kubernetes platform," you will likely be met with polite nods followed by quiet inaction — or worse, active resistance.

Authority vs. Influence: A Concrete Distinction

These two concepts are often confused, but they produce very different outcomes:

  • Authority is the formal right to command, granted by your job title or organizational hierarchy. It produces compliance — people do the thing, but only because they have to. The moment the authority disappears, so does the behavior.
  • Influence is the ability to shape others' decisions, actions, and beliefs through trust, logic, and relationships. It produces commitment — people do the thing because they genuinely believe it is the right move.

In platform engineering, compliance is fragile. If a team adopts your tool only because they were told to, they will find workarounds, skip updates, and blame the platform the moment anything goes wrong. Commitment is durable. A team that chose your platform because they understood its value will advocate for it, contribute improvements, and help onboard others.

To drive lasting change, you must learn to influence — to sell ideas, build consensus, and make people want to move in the direction you are pointing.

Interview Tip

Interviewers at senior and staff-level roles frequently ask: "Tell me about a time you drove a significant technical change without having direct authority over the teams involved." The expected answer structure is: (1) describe the problem and why it mattered, (2) explain how you identified and engaged stakeholders, (3) describe the specific influence tactics you used, and (4) quantify the outcome. Answers that skip step 2 or 3 signal a candidate who relies on authority rather than influence.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free