Cloud-native teams are different by design. They’re distributed, cross-functional, and deliberately flat. Today’s engineering environments operate on a flat plane, driven by microservices, DevOps, and decentralized “two-pizza teams.” Developers own their services end-to-end. Platform engineers operate as internal product teams. SREs, security engineers, and data architects work across organizational boundaries without direct reporting lines. There’s no single command-and-control center, and that’s the point.

However, the technical expertise is only half of the battle. This structure creates a challenge that technical training rarely prepares people for because you have no authority or title that demands compliance. So, how do you get things done when you have no authority over the people you depend on? How do you drive adoption of a new observability standard, advocate for a platform migration, or push for better security practices across a dozen autonomous teams?

The answer isn’t political maneuvering or charm. It’s a specific set of soft skills that, when practiced consistently, build something more durable than authority. They build genuine influence. Building influence without authority is an art, and it’s the ultimate soft skill for modern technologists. Read on for 5 tips to help you build genuine influence in today’s engineering environment.

Tip 1: Recognize that Credibility Is the Currency

In flat, cloud-native organizations, influence starts with credibility — and credibility is earned through demonstrated competence and intellectual honesty. People follow people who clearly know what they’re talking about and are honest about what they don’t know.

This means resisting the temptation to overstate certainty. If you’re proposing a shift to a service mesh and someone asks about latency implications, “I’m not sure yet, but here’s how I’d find out” lands better than a confident answer you haven’t fully thought through. Over time, teams calibrate who they can trust to give them straight information. Becoming that person in your organization is the single most important thing you can do to build influence without a title.

Credibility also comes from follow-through. In distributed teams, promises made in Slack or a design doc often have no formal enforcement mechanism. The engineers who consistently do what they say they’ll do — review the PR, update the runbook, show up to the post-mortem — quietly accumulate a kind of social capital that titles can’t manufacture.

When you advocate for a change, don’t frame it as a technical best practice. Frame it as a solution that reduces the 2 AM wake-up calls for the SRE team. When you solve a human pain point, you build credibility, and your influence grows exponentially.

Tip 2: Help Others When They Have Problems

One of the most overlooked influence-building strategies is genuine investment in other teams’ success. In cloud-native environments, teams are often siloed around services or domains. It’s easy to stay in your lane. The engineers who build cross-team influence are the ones who don’t.

This doesn’t mean overstepping. It means paying attention to what other teams are struggling with and showing up with something useful like a tool, a pattern, a piece of documentation, or a conversation. When the platform team builds an internal developer portal because they listened to developers complain about service discovery for six months, they earn something no mandate could give them: genuine buy-in.

The principle here is reciprocity. When you help people solve their problems without being asked and without expecting credit, they become invested in your success. This isn’t control — it’s the foundation of functional collaborative culture.

Tip 3: Communicate in the Language of the Audience

Technical influence is often lost in translation. Sure, the SRE who wants teams to adopt structured logging has a strong case. But, if they present it as a reliability argument to a product manager, or as a compliance story to a developer who cares about ergonomics, the message won’t land. Worse, it may generate resistance even from people who would otherwise agree.

Effective influencers in cloud-native teams learn to read their audience and adapt to their audience’s area of interest. For engineering leads, the argument is technical elegance and reduced incident noise. For product managers, it’s faster debugging and less time spent in war rooms. For finance stakeholders, it’s reduced mean time to recovery and lower operational costs. The underlying recommendation is identical; it’s the framing and the lens that changes.

Communicating in your audience’s language requires empathy. At Samtek, we reinforce this approach intentionally. We recently held an internal workshop focused on how we communicate across teams and to multiple audiences. The emphasis wasn’t simply on “alignment,” but rather it was on how to speak with a consistent voice that demonstrates three things clearly: we heard the concern, we understand the underlying issue, and we’re taking thoughtful action in response. The workshop reinforced that consistency in communication builds trust. People don’t expect perfect uniformity in healthy organizations, but they do expect clarity, professionalism, and evidence that concerns are being taken seriously. Speaking with one voice doesn’t mean eliminating different perspectives; it means ensuring those perspectives are communicated in a way that creates confidence rather than confusion. An empathetic approach to communication is the ability to step outside your own perspective and ask, genuinely, “What does this person care about, and how does my proposal connect to that?” It sounds simple. It’s surprisingly rare.

Tip 4: Navigate the “Opinion vs. Data” Gap

In a high-velocity cloud environment, opinions are cheap. If you want to influence a team of engineers, you need to bring objective telemetry. In other words, show, don’t tell.

If you believe the team should adopt a new serverless framework, don’t just say it’s “better” – show the data. Use a proof-of-concept (PoC) to demonstrate how it reduces cold starts or cuts cloud spend by 15%. When you lead with data, you remove the “ego” from the room. It becomes much harder for someone to use their authority to block an idea when the data clearly supports your path. As an example, at Samtek, to familiarize both our team and our CMS stakeholders with a proposed solution, we presented our dual-stack IP network architecture and configuration details during an Agile Program Increment (PI) Demo. By clearly demonstrating the technical approach and the supporting data, we built stakeholder confidence and secured buy-in to move forward, helping ensure that decisions were guided by evidence rather than individual authority or preference.

Tip 5: Recognize Disagreement as a Relationship Asset

In organizations without formal authority structures, productive disagreement becomes a signal of respect. When you challenge an architectural decision thoughtfully — with evidence, with alternatives, with an acknowledgment of the tradeoffs — you demonstrate that you take the work seriously and that you trust the relationship enough to be honest.

The key word is thoughtfully. Drive-by criticism in a pull request or a sharp comment in a public Slack channel erodes the influence you’ve built. Influence-building disagreement is:

• Private (where possible)
• Specific (rather than personal)
• Always oriented toward shared outcomes

A healthy engineering culture is one where people feel safe enough to challenge ideas, but disciplined enough to do it with context, evidence, and respect. Think of it like a bank transaction: “I think this approach creates a bottleneck at scale, and here’s an alternative worth considering” is a relationship deposit. “This is wrong” is a withdrawal.

Tip 6: Focus on Consistency Over Intensity

The final and perhaps most important insight about influence without authority is that it compounds slowly and erodes quickly. It isn’t built in a single impressive presentation or a heroic incident response. It’s built through hundreds of small, consistent actions: the clear write-up, the honest estimate, the credit given to teammates, the willingness to say, “I was wrong.”

In cloud-native teams, where collaboration is constant and memory is long, who you are over time matters far more than who you are in any single moment. Build your influence like you’d build a reliable system — incrementally, with feedback loops, and designed to last.

Takeaway: Choose the Servant-Leader Mindset

Influence without authority is not about manipulation; it is about service. The most influential people in cloud-native teams aren’t the ones who shout the loudest or have the most impressive titles. They are the ones who make everyone else’s job easier.

When you focus on removing friction, sharing knowledge, and aligning technical goals with human needs, authority becomes irrelevant. People will follow you not because they must, but because you have proven that your direction leads to a more stable, scalable, and sane working environment.

In the cloud, that is the only authority that truly matters.

Check out our blogs on Effective Collaboration Between Cloud Engineers and How to Communicate Complex Architectures to Non-Technical Stakeholders to read more about the way we approach our work — we call it the Samtek Difference.