Leading Teams That Don’t Report to You

You own delivery for a 25-person team—but only two report to you. That’s the new normal in engineering leadership. Nearly 70% of enterprise software teams now operate in blended models of employees, vendors, and contractors.

Enterprises adopt blended delivery models not just to control costs, but also to boost capacity flexibility, access specialized skills, and reduce hiring risks in volatile markets. The model benefits the business—yet it weakens accountability. Integration replaces hierarchy, but incentives remain siloed.

The Paradox of Control

Modern delivery models reshaped hierarchy. Work is integrated—but accountability and incentives remain fragmented. Leaders face a mismatch—full responsibility, little control. Influence now replaces authority.

The Leader’s Dilemma

You coordinate delivery across employees, vendors, and contractors—each with different incentives and reporting lines.

You’re accountable for outcomes, but hold almost none of the leverage to hire, fire, or reward performance.

In this environment, hierarchy often hinders progress. You must shift from positional power to earned influence—the core of embedded leadership, where influence matters more than title. It’s about motivating, aligning, and sustaining performance across boundaries.

The Foundation: Trust and Technical Credibility

Embedded leadership rests on two pillars: relational trust and technical credibility—the currency of influence when authority is scarce.

The first pillar starts in your one-on-ones.

Pillar 1: One-on-Ones as Leverage

These aren’t status updates; they’re developmental conversations focused on growth, goals, and friction points. I hold weekly 1:1s with key contributors, biweekly with most, and monthly with others—frequent enough for support, light enough to avoid overload.

When a contractor struggles, respond collaboratively: “Let’s pair with a senior engineer.” That signals investment, not judgment. This trust turns contractual relationships into genuine partnerships.

When a contractor consistently improved architecture or delivery, I used data on their impact to justify a conversion—proof that development-focused trust creates business value.

Always frame it as capability-building that benefits everyone, not poaching. Before pursuing conversions, ensure alignment with company policy and vendor agreements, as boundaries vary.

Pillar 2: Earning Technical Credibility

Influence isn’t granted; it’s earned through technical credibility shown in real work. The embedded leader acts as a technical steward—keeping architecture aligned with vision while guiding trade-offs and mentoring leads.

When interventions repeatedly improve quality, reduce blockers, or clarify trade-offs, credibility compounds. Authority is earned through competence, not granted by position.

With trust and credibility in place, influence only matters if it drives delivery. Three habits turn that influence into measurable results.

Three Practices That Turn Influence into Results

Trust and credibility open doors. These three practices turn influence into delivery.

Practice 1: Data as the Shared Language

Without formal authority, data becomes the shared language of accountability. It replaces opinion with evidence and shifts conflict from blame to problem-solving.

Saying “Team X’s PR cycle time increased 30% while defect rate doubled” doesn’t accuse—it invites collaboration. Metrics expose systemic causes—such as tooling gaps, unclear requirements, or competing priorities—making improvement a shared responsibility.

Use metrics as health indicators, not weapons. Flow and quality data surface issues early, keeping accountability grounded in facts rather than feelings.

Data professionalizes disputes; relationships resolve them.

But data alone doesn’t resolve tension—it creates the conditions for productive dialogue. When metrics surface problems, the embedded leader must navigate vendor relationships with both clarity and diplomacy.

Depersonalize Conflict

When delivery slips or quality drops, meet with vendor leads to understand their constraints—utilization targets, skill gaps, or competing priorities—and co-design solutions. Data turns tense conversations into joint problem-solving.

Practice 2: The Alignment Framework

Blended teams often lose sight of the “why.” The leader’s job is to connect each sprint goal to the business story.

Making the Mission Real

Replace “Complete ticket X” with:

“This change removes friction from sign-up, improving activation by 5% this quarter.”

Framing work in business terms reinforces shared purpose. Begin standups and retros with outcomes, not activity.

Practice 3: Structure That Empowers Autonomy

Alignment clarifies the why; structure defines the how. Together, they make autonomy safe and scalable across boundaries. Many organizations adapt frameworks inspired by Spotify’s model that coordinates autonomous teams through three complementary mechanisms:

The Three Essential Structures

• Practice Groups: drive craft excellence—align by discipline, define standards, raise technical quality.

• Product Streams: deliver customer value—organize around outcomes, own delivery, measure impact.

• Communities of Practice: enable shared improvement—spread knowledge, solve cross-cutting concerns, spark innovation.

Autonomy in Action

In practice, individual contributors gain clarity by operating in all three: they learn standards (Practice Groups), make local decisions (Product Streams), and innovate (Communities of Practice).

Concrete example: When a backend engineer needs to add a new API endpoint, they consult the Backend Practice Group’s standards for authentication patterns and error handling, deliver the feature within their Product Stream’s sprint commitments, and might share their caching strategy in the API Design Community to help others facing similar challenges.

When engineers know the standards, decision-making channels, and innovation channels, autonomy expands safely. A clear structure turns independence into alignment.

When these structures work in concert—trust opening doors, credibility shaping decisions, data grounding conversations, alignment connecting purpose, and systems enabling autonomy—they compound into something greater than their parts.

Influence That Outlasts Authority

This isn’t leadership despite lacking authority—it’s leadership because of it.

Embedded leadership isn’t about ignoring the org chart; it’s about building relational authority—earned through persistent trust, technical credibility, and clarity. It transforms organizational complexity into coordination that endures through management or vendor changes.

But relational authority isn’t self-sustaining. It requires judgment and boundaries: one-on-ones need thoughtful distribution; vendor ties need clear lines. Influence works—until it meets immovable constraints. That’s when leadership shifts from influence to decision.

Influence works until consequences become asymmetric—when the downside of waiting exceeds the cost of acting. The embedded leader’s craft isn’t avoiding authority; it’s knowing precisely when to reassert it. Influence moves teams forward; authority protects the business when the stakes rise.

When coaching and data no longer solve chronic issues, escalate through formal channels—whether that’s vendor leadership or your own chain of command. The key is knowing when to use influence and when to deploy authority—and building one when the other fails.

In today’s blended teams, hierarchy defines structure, but influence drives scale. As engineering organizations lean further on distributed talent and AI-augmented workflows, relational authority will determine how leaders sustain both trust and velocity. Influence shapes the product; foresight scales the organization.