5 Bases of Power Audit for Tech Leads (Scorecard)

As an Amazon Associate I earn from qualifying purchases. Product links on this page are affiliate links — they cost you nothing extra.

⏱ 24 min read

What French and Raven Power Bases Mean in Tech

Engineering influence relies on five distinct sources of leverage first identified by social psychologists John French and Bertram Raven: Legitimate, Reward, Coercive, Expert, and Referent power. In software organizations, positional power (Legitimate, Reward, and Coercive) depreciates rapidly because technical output depends on voluntary cognitive effort rather than mechanical compliance. Tech managers fail when they substitute formal rank for earned technical credibility and relational trust. Sustainable team velocity requires anchoring your leadership in Expert and Referent authority instead of managerial fiat.

Legitimate power is authority derived strictly from an official corporate title or reporting line that grants a person the formal right to issue instructions. In a traditional corporate hierarchy, that formal title carries automatic weight. A factory supervisor or department head issues a command, and compliance follows because the organizational chart demands it.

Knowledge work operates under entirely different economic and social rules. As researcher Linda Hill documented in her Harvard Business School study Becoming a Boss, new managers routinely stall because they mistake positional compliance for genuine commitment. Software engineering requires deep problem-solving, architectural discretion, and silent vigilance over edge cases. A manager cannot force an engineer to care about distributed race conditions or silent database failovers through command-and-control mandates.

When software leaders attempt to enforce decisions purely through positional rank, understanding power dynamics in teams becomes an urgent priority. Positional power devalues the moment a team realizes their manager lacks context. If you demand that an infrastructure team push an unvalidated patch by Friday at 5:00 PM simply because "the roadmap requires it," you burn through relational capital in minutes. The team may ship the code to avoid confrontation, but code quality collapses, technical debt mounts, and post-incident cleanup consumes the next 3 weeks of roadmap capacity.

Positional Power
(Decays under friction)
  |
  v
Directives
  |
  v
Passive Compliance
  |
  v
Technical Attrition

This friction peaks when an engineering manager clashes with Senior, Staff, or Principal engineers. In his book Staff Engineer, author Will Larson notes that high-level individual contributors often wield significantly more organizational influence and domain expertise than the engineering managers handling their administrative reviews.

Consider a standard planning session. An engineering manager insists on migrating an internal payment pipeline to a new cloud service to meet a quarterly executive milestone. The Staff engineer objects, citing unhandled retry storms and undocumented upstream dependencies that will double latency under high concurrency. If the manager responds with legitimate power—invoking rank by saying, "I own delivery for this team, and this is the decision"—friction instantly hardens into gridlock.

The Staff engineer disengages. They stop flagging architectural risks, they refuse to mentor junior developers on that system, and they redirect their best efforts elsewhere. According to Gallup’s State of the American Manager report, 50% of employees who leave their jobs do so to get away from their immediate manager. In tech, highly skilled individual contributors do not submit to title-based bullying; they update their LinkedIn profiles and accept offers from competing engineering organizations within 30 days.

Building foundational tech leadership skills requires mastering the transition from organizational dominance to earned credibility. When managers lack technical depth in a legacy system, they must lead through Referent power—interpersonal respect, transparent trade-offs, and mutual trust—while relying on the Expert power of their senior staff. Replacing authority with genuine influence prevents high-friction standoffs and keeps institutional knowledge inside the building.

Recognizing where your authority actually comes from is only the first step. To understand exactly how your current leadership style measures up against your team’s expectations, you must measure your daily behaviors across each specific power base using the diagnostic scoring model below.

Table of Contents

• What French and Raven Power Bases Mean in Tech
• How Positional and Personal Power Divide Engineering Teams
• Warning Signs of Overreliance on Legitimate Authority
• How to Conduct the 5 Bases Influence Audit
• Four Shifts to Build Referent and Expert Leverage
• The 5-Minute Power Audit Diagnostic Scorecard
• Sources & Further Reading

How Positional and Personal Power Divide Engineering Teams

Engineering teams fracture when managers mistake positional authority for technical leadership. Social psychologists John French and Bertram Raven established in their 1959 study at the University of Michigan that social power splits into positional forms derived from title and personal forms derived from relationships and competence.

Positional power means organizational authority that exists solely because a company granted an individual a specific title or job level, giving them administrative control over company resources, task assignments, and formal evaluations rather than earned personal influence.

When engineering leaders lean on this administrative leverage, execution speed drops and software architecture degrades. Mastering technical leadership skills development requires diagnosing how each base shows up on the engineering floor.

Positional Power: Legitimate, Reward, and Coercive

Positional power relies on three distinct bases that dictate compliance through top-down leverage:

• Legitimate Power: This is title-based mandate. It appears in sprint planning when a manager overrides a sizing estimate by stating, "I am the engineering lead, so we are committing to 45 story points this sprint." The team yields to the authority of the org chart rather than realistic engineering velocity.
• Reward Power: This leverages incentives such as high-visibility project assignments, equity refreshes, or year-end bonuses. In one-on-one meetings, a manager might hint that a senior engineer will receive an exceeding-expectations rating in their effective performance appraisal techniques only if they take on unbudgeted infrastructure firefighting outside normal sprint boundaries.
• Coercive Power: This enforces compliance through explicit or implicit threats, such as poor performance reviews, project reassignment, or mandatory weekend coverage. During production incidents, coercive leaders threaten public blame, which drives developers to hide bugs or delay post-incident reports.

DORA’s 2023 Accelerate State of DevOps Report analyzed over 36,000 working professionals worldwide and found that high-performing teams exhibit 30% higher operational performance when managers foster psychological safety over punitive management. Relying on positional authority reliably triggers compliance rather than commitment. Engineers do the bare minimum required to satisfy the sprint contract, avoid punishment, and protect their appraisal score.

Personal Power: Expert and Referent

Personal power functions without administrative leverage. It relies on the team’s internal choice to follow the leader’s direction based on two foundational bases:

• Expert Power: This is influence built on specialized domain knowledge and sound judgment. It governs technical consensus during pull-request (PR) reviews. When a principal engineer suggests breaking a monolithic database query into smaller batch operations, the author accepts the feedback because the reviewer has proven expertise in Postgres query planning, not because they manage the author’s compensation.
• Referent Power: This is influence earned through interpersonal trust, transparency, and shared values. It drives architectural alignment across distributed services. When an architect asks multiple service teams to adopt OpenTelemetry tracing standards, teams prioritize the refactoring because the architect has earned professional respect by helping resolve past critical incidents. Developing this alignment is a key milestone in foundational tech leadership skills.

Google’s two-year Project Aristotle study across 180 engineering teams identified psychological safety as the primary driver of team effectiveness. Teams guided by personal power encourage healthy technical dissent during system design reviews, leading to resilient systems and cleaner abstractions.

Developer Behavioral Differences Under Positional vs. Personal Power

The operational gap between command-and-control authority and high-trust influence appears directly in codebase health, sprint metrics, and attrition.

       POWER DYNAMICS IN CODE REVIEWS
       
     [Manager Uses Positional Power]
                   |
                   v
     Engineer makes silent changes
                   |
                   v
     PR approved without debate
                   |
                   v
     Hidden tech debt enters main
                   |
                   v
     [Manager Uses Personal Power]
                   |
                   v
     Engineer challenges assumption
                   |
                   v
     Debate uncovers edge case
                   |
                   v
     Resilient, tested architecture

Under command-and-control managers, developer interaction turns defensive:

• Sprint Planning: Engineers deliberately pad estimates by 50% to 100% to create a safety margin against coercive milestone changes. Under high-trust personal influence, engineers share unpadded sizing because they know missed estimates trigger retrospective problem-solving, not punitive reviews.
• Code Reviews: Positional teams experience "rubber-stamp" pull requests. Developers approve PRs in under 5 minutes without testing local builds to dodge confrontation with authoritarian leads. High-trust teams spend an average of 45 minutes examining diffs, discussing edge cases, and proposing alternatives without fear of offending the reviewer.
• Architectural Alignment: Positional teams implement top-down architectural mandates poorly. Engineers build workarounds around mandated libraries, accumulating hidden operational tech debt. High-trust teams actively debate design docs in open RFC (Request for Comments) threads, aligning on trade-offs before writing production code.

Understanding these operational behaviors is critical when leading high-performing tech teams through high-pressure release cycles.

POSITIONAL POWER (ADMINISTRATIVE COMPLIANCE)
* Legitimate: Title-driven authority ("I lead this sprint")
* Reward: Incentives, bonuses, favorable project assignments
* Coercive: Negative reviews, punitive on-call, threats
Outcome: Defensive sizing, hidden tech debt, 5-min PR approvals

PERSONAL POWER (AUTONOMOUS COMMITMENT)
* Expert: Domain depth, proven architecture track record
* Referent: Interpersonal trust, psychological safety
Outcome: Transparent estimates, thorough reviews, fast recovery

OPERATIONAL RULE
Use positional power only to unblock organizational friction.
Use personal power to drive code, architecture, and standards.

Knowing how these five power bases operate across daily technical workflows is the first step toward correcting broken team dynamics. To measure your own balance across these bases and uncover where administrative habits may be harming your team’s velocity, you need an objective measurement framework. The diagnostic scorecard in the next section provides the concrete rubric to evaluate your engineering leadership baseline.

Warning Signs of Overreliance on Legitimate Authority

Tech managers who substitute formal organizational rank for genuine team consensus stall technical delivery and drive out senior engineering talent.

Legitimate authority is power derived strictly from an individual’s formal job title and organizational rank rather than their technical competence, interpersonal respect, or ability to influence others through persuasion. When engineering managers lean on this title-based power to push decisions through, they trigger three destructive behavioral shifts across their engineering teams.

The first breakdown is the expert trap. This happens when a manager relies on technical choices they made years ago instead of supporting team-led architecture. Camille Fournier details this failure mode in her management manual The Manager’s Path.

A manager who wrote production services in Python five years ago often insists on obsolete patterns, bypassing modern asynchronous frameworks and automated testing. According to Google Cloud DORA research, teams with high architectural autonomy deploy code 4.2 times more frequently than teams bound to centralized, managerial approvals. Forcing outdated patterns stunts technical leadership skills development across your senior engineers, who eventually stop submitting design documents altogether.

The second breakdown is coercive drift. When a manager uses subtle threats, like reassigning engineers to maintenance duty after a disagreement, the team protects itself by disengaging. Sprint retrospectives shrink from 45 minutes of debate to 10 minutes of complete silence. Pull requests on GitHub get rubber-stamped with approvals in under 3 minutes without a single code review comment. As Amy Edmondson documents in The Fearless Organization, command-driven cultures cause 63% of technology workers to withhold information about critical operational risks. This erosion ruins basic problem-solving techniques for leaders, leaving catastrophic production incidents undiscovered until launch day.

The third breakdown is reward erosion. Managers frequently compensate for a lack of genuine buy-in by offering low-effort perks, such as branded company swag or celebratory pizza dinners. In Drive, author Daniel Pink showed that superficial extrinsic tokens fail to motivate technical knowledge workers who require autonomy, mastery, and purpose. High-performing software engineers do not want gift cards; they want ownership of distributed database redesigns, visibility in executive demos, and clear career equity. When managers fail to offer meaningful scope, senior staff view the praise as an empty distraction and update their resumes.

Identifying these failure points early is critical to understanding power dynamics in teams. Use the comparison matrix below to audit whether your team shows signs of managerial overreach.

Before you can recalibrate your influence across these vectors, you must grade your team against the five quantitative power benchmarks in the diagnostic scorecard below.

How to Conduct the 5 Bases Influence Audit

A French and Raven power audit evaluates whether your engineering leadership relies on formal organizational authority or earned technical trust. Developed by social psychologists John French and Bertram Raven at the University of Michigan in 1959, this framework splits managerial authority into five distinct sources: Legitimate, Reward, Coercive, Expert, and Referent power.

Positional power is the formal authority granted to a leader by an organization’s organizational chart, including the right to assign work, mandate compliance, reward performance, and enforce disciplinary consequences. In contrast, personal power comes from your individual competence and your interpersonal standing with colleagues. Auditing these forces takes three structured steps.

Step 1: Log Your Last 10 Technical Decisions

Pull your commit history, Slack threads, and architectural review logs from the past 60 days. Identify the last 10 critical technical decisions where you needed team alignment, such as adopting a new microservices framework, adjusting technical debt allocations, or changing an on-call rotation.

For each decision, identify the dominant base of power you used to gain agreement:

• Legitimate Power: You invoked your managerial title or company policy ("As the engineering director, I decided we are standardizing on AWS").
• Reward Power: You traded benefits or perks for compliance ("Take this migration sprint, and you will lead the greenfield project next quarter").
• Coercive Power: You relied on implicit or explicit penalties ("If this deadline slips again, weekend coverage becomes mandatory").
• Expert Power: You persuaded through domain knowledge, data analysis, or architecture benchmarks ("Our load tests show latency spikes at 5,000 concurrent requests on this Redis setup").
• Referent Power: You leveraged mutual trust, shared values, and professional respect ("The team agreed to back this refactoring push because they believe in the team charter we built").

Record this data in a spreadsheet. If you find that more than 3 of your last 10 decisions relied on Legitimate, Reward, or Coercive power, your team operates on compliance rather than buy-in. Mastering foundational tech leadership skills requires shifting those tallies toward Expert and Referent power bases.

Step 2: Collect Anonymous Cross-Functional Signal

Self-assessments carry blind spots. Your peers and direct reports experience your authority differently than you perceive it, making external feedback essential to understanding power dynamics in teams.

Set up an anonymous, three-question poll in Google Forms and send it to 4 to 6 cross-functional partners, including Product Managers, Quality Assurance leads, and Staff Engineers. Give them a 5-day response window and ask:

1. When I propose a technical pivot, do you agree because of the data presented, or because of my organizational role?
2. In which recent sprint did you feel forced to accept a technical direction you disagreed with?
3. How confident are you that questioning an architectural decision will lead to an open debate rather than managerial pushback?

Review the responses to identify where your influence breaks down across departments. For example, you might maintain high Expert power with junior developers who value your debugging expertise, yet lean on Legitimate power with Product Managers because you struggle to frame engineering trade-offs in commercial terms. This breakdown indicates a need for targeted technical leadership skills development to balance your approach.

Step 3: Calculate Your Personal-to-Positional Power Ratio

The final step aggregates your decision audit and feedback signals into an operational ratio. Group your 10 decisions from Step 1 into two buckets:

\(\text{Personal Power Score} = \text{Expert Decisions} + \text{Referent Decisions}\)

\(\text{Positional Power Score} = \text{Legitimate} + \text{Reward} + \text{Coercive Decisions}\)

Divide your Personal Power Score by your Positional Power Score to establish your Power Ratio. If you logged 7 personal decisions and 3 positional decisions, your ratio is 2.33:1.

\(\text{Power Ratio} = \frac{7}{3} = 2.33\)

Healthy software teams require a minimum Personal-to-Positional Power Ratio of 2.0:1. When this ratio drops below 1.0:1, managers face elevated attrition risks, passive-aggressive sprint delays, and silent architectural drift.

Running this quick calculation prior to your next 14-day sprint planning session highlights whether your team executes work because they value your technical vision or simply because your title leaves them no choice. If your ratio reveals an over-reliance on positional leverage, pairing this diagnostic with a structured skill gap audit for engineering managers will pinpoint the exact communication deficits driving that imbalance.

Before you apply these metrics to your next retrospective, examine the diagnostic scorecard below to grade your team’s baseline across every individual base.

Four Shifts to Build Referent and Expert Leverage

Engineering managers build durable influence by replacing positional authority with personal leverage across four tactical operational shifts. John French and Bertram Raven’s foundational 1959 research at the University of Michigan demonstrated that while legitimate and coercive power produce mere compliance, expert and referent power generate genuine commitment.

Referent power is the interpersonal influence an engineering leader earns when colleagues identify with their values, respect their judgment, and choose to follow their example voluntarily.

To shift your baseline, you must systematically re-engineer how you make technical decisions, handle outages, enforce delivery standards, and distribute project visibility. This transition is essential for technical leadership skills development and changes how staff engineers and senior developers respond to your guidance.

+------------------------------------------+
|       TRADITIONAL DIRECT CONTROL         |
|  (Solving bugs, fiat rules, scolding)    |
+------------------------------------------+
                    |
                    v
+------------------------------------------+
|        SYSTEMIC LEVERAGE MODEL           |
|  (Boundaries, automation, sponsorship)   |
+------------------------------------------+

Shift 1: Define Boundaries Instead of Writing Code

Stop debugging production issues for your team. When managers solve complex tickets directly, they undermine their engineers’ autonomy and burn roughly 15 hours per week that belong on organizational strategy. Shift your expert leverage toward defining architectural boundaries, clear input/output constraints, and explicit trade-off criteria.

According to Camille Fournier in The Manager’s Path, an engineering leader’s primary technical role is setting technical context rather than dictating solutions. Document your non-negotiable operational boundaries using Architecture Decision Records (ADRs). When teams know that system latency must stay under 120 milliseconds at p99 and infrastructure cost must remain below $0.04 per active user, they make sound tactical decisions without waiting for managerial sign-off. This framework is central to understanding power dynamics in teams because authority moves from your title to the engineering parameters.

Shift 2: Run Blameless Post-Mortems to Solidify Referent Power

Coercive managers search for individuals to blame when services degrade. Referent managers audit systemic failure points in public. When an outage occurs, demonstrate vulnerability by publishing a transparent failure analysis within 48 hours of service recovery.

Google’s Site Reliability Engineering framework documents that psychological safety increases when leaders treat incidents as design flaws rather than personnel failures. State your own procedural misses explicitly in the timeline. If you approved an aggressive release schedule that squeezed validation windows, write that choice directly into the post-mortem incident report. When you normalize public accountability without defensive posturing, you eliminate the fear that suppresses incident reporting, a key tenet for leading high-performing tech teams.

Shift 3: Deprecate Coercive Pressure via CI/CD Governance

Replace executive intervention and emergency Slack escalations with automated enforcement mechanisms. Coercive pressure erodes retention; Gartner reported in a 2023 workforce survey that 47% of tech workers cite intrusive, coercive oversight as a primary trigger for actively seeking new employment.

Move policy enforcement entirely into your continuous deployment pipeline. If test coverage drops below 85%, or if a dependency carries a critical Common Vulnerabilities and Exposures (CVE) score above 7.0, let GitHub Actions or GitLab CI reject the pull request. Establish team-agreed working agreements during sprint retrospectives, then encode those standards into automated linters and merge rules. When an automated check blocks deployment, the pipeline enforces quality, not managerial temperament.

Shift 4: Map High-Visibility Work to Career Objectives

Positional managers use project assignments as arbitrary favors. Leaders with sustainable reward power connect mission-critical architecture efforts directly to developer career growth.

Dr. David Rock’s SCARF model, published by the NeuroLeadership Institute, demonstrates that perceived status and autonomy directly drive engagement. During your bi-weekly 1:1 meetings, identify the specific capabilities your senior engineers need to demonstrate for promotion—such as distributed data pipeline design or cross-team consensus building. Assign the technical lead slot on that $250,000 cloud-migration initiative to an engineer targeting a principal promotion, not to yourself. You amplify your own influence by serving as an active sponsor rather than the central bottleneck.

Executing these behavioral shifts requires auditing where your current baseline sits across every dimension of your team’s operational routine. The diagnostic scorecard below maps your exact score across all five bases of power so you can prioritize your high-leverage corrections.

The 5-Minute Power Audit Diagnostic Scorecard

The 5-Minute Power Audit Diagnostic Scorecard measures how an engineering manager distributes influence across John French and Bertram Raven’s five foundational power bases: Legitimate, Reward, Coercive, Expert, and Referent. In studies published in the Journal of Applied Psychology, researchers Gary Yukl and Cecilia Falbe found that personal power bases (Expert and Referent) correlate over 50% more strongly with subordinate compliance and commitment than positional power bases (Legitimate, Reward, and Coercive). Relying on the wrong base stalls team velocity, spikes unwanted turnover, and turns delivery deadlines into political battles.

French and Raven defined interpersonal power as the ability of an individual to alter the behavior or beliefs of another person in a social system. In technical organizations, this means whether an engineer submits a pull request on Friday evening because they fear your performance review, or because they trust your technical vision.

15-Question Power Base Assessment

Score each statement from 1 to 5 based on how accurately it describes your behavior over the past 90 days:

• 1 = Never (0% of the time)
• 2 = Rarely (25% of the time)
• 3 = Sometimes (50% of the time)
• 4 = Often (75% of the time)
• 5 = Always (100% of the time)

Legitimate Power (Authority & Title)

1. When engineers push back on team priorities, you invoke company hierarchy, your title, or executive mandate to settle the discussion.
2. You expect adherence to sprint schedules primarily because process compliance is an official policy in the engineering handbook.
3. You allocate unglamorous technical debt or on-call rotations based on seniority rather than consensus or rotating schedules.

Reward Power (Carrots & Incentives)

4. You explicitly trade desirable project assignments, high-visibility greenfield work, or conference budgets for team compliance on sprint goals.
5. You use discretionary bonuses, spot awards, or title advancement as your primary leverage to secure late-night release support.
6. You notice team members aligning with your opinions during roadmap debates mainly when end-of-year compensation reviews approach.

Coercive Power (Sticks & Pressure)

7. You remind engineers about negative performance reviews, PIP risks, or missed equity cliffs when sprint delivery falls behind.
8. You reassign struggling developers to maintenance tasks or pull them off key architectural projects without a clear remediation path.
9. Engineers hesitate to report failed deployments or architectural bugs to you until the incident becomes public.

Expert Power (Technical Credibility)

10. Engineers bring complex architectural problems, system design trade-offs, and critical bugs to you because you consistently spot edge cases they missed.
11. You actively contribute to technical reviews by providing domain context that simplifies systems and eliminates refactoring cycles.
12. Engineers adopt your proposed system architectures because your past design decisions demonstrated high uptime and low operational overhead.

Referent Power (Trust, Shared Identity, & Respect)

13. Engineers on other teams request lateral transfers into your group specifically to work under your guidance.
14. Direct reports openly discuss their skill gaps, career anxieties, and mistakes during one-on-one meetings without fear of judgment.
15. When a production incident occurs, engineers follow your lead calmly because you shoulder systemic accountability rather than seeking individual blame.

Scoring and Diagnostic Result Benchmarks

Sum your points for each power base (minimum score 3, maximum score 15 per base). Then calculate your Positional Index and your Personal Index:

Positional Index = Legitimate + Reward + Coercive
Personal Index   = Expert + Referent

Compare your totals against three primary archetypes:

      [Positional Index >= 30]
                 |
      +----------+----------+
      |                     |
[Personal < 18]       [Personal >= 18]
      |                     |
Positional Enforcer     Multiplier
      |
      | (If Expert >= 12, Referent < 8)
      v
Technical Bottleneck

1. The Positional Enforcer (Positional Index ≥ 30, Personal Index < 18)

You manage through policy, mandates, and formal rank. Your direct reports deliver the minimum required output to satisfy tickets and avoid reprimands. Attrition among senior ICs usually exceeds 20% annually in this profile. To reverse this pattern, build core competencies in Understanding Power Dynamics in Teams to replace mandates with social proof and shared ownership.

2. The Technical Bottleneck (Expert Score ≥ 12, Referent Score < 8)

You command respect purely through technical brilliance, but you act as an architectural gatekeeper. Code reviews wait 48 hours for your personal sign-off, system diagrams require your stamp, and your team lacks autonomy. You create delivery risks by centralizing context. You must prioritize Technical Leadership Skills Development that shifts your focus from individual execution to mentoring and team enablement.

3. The Multiplier (Personal Index ≥ 24, Positional Index ≤ 20)

Engineers follow your direction because they trust your decisions, value your feedback, and feel protected under your leadership. You deploy legitimate authority only during catastrophic deadlocks or compliance events. According to research published by Harvard Business Review, leaders who operate as multipliers extract nearly double the capability from their existing staff compared to diminishers who rely on command-and-control pressure.

30-Day Corrective Action Matrix

Use this weekly protocol to systematically decrease reliance on coercive mandates and rebuild lagging expert and referent influence. Applying clear Goal Setting Techniques for Team Performance across each phase ensures measurable behavioral changes.

Strengthening these bases is central to Foundational Tech Leadership Skills and sustained execution in Leading High-Performing Tech Teams. Practicing core principles from Master Active Listening: Your Leadership Superpower directly accelerates your Week 2 referent targets by making your team feel heard during stressful delivery phases.

Calculate your scorecard totals right now, highlight your single lowest-scoring power base, and execute the Day 1 micro-habit for that quadrant before your next standup.

Sources & Further Reading

Social power diagnostic audits in technical management rest on empirical social psychology frameworks developed across six decades of workplace research.

Social power is the potential ability of an individual to influence the attitudes, beliefs, or behaviors of another person within an organizational setting. When technical leads rely solely on formal authority, their teams suffer measurable friction. Empirical research published by Gary Yukl in Leadership in Organizations indicates that personal power bases like expert and referent power yield follower commitment rates exceeding 50%, whereas position-based compliance rarely surpasses 15%.

For engineering managers balancing architecture reviews, roadmap priorities, and career mentorship, understanding which base drives team execution is essential. The seminal research conducted by John R. P. French Jr. and Bertram Raven at the University of Michigan established the initial taxonomy of five distinct power bases in 1959, before Raven formally added informational power 6 years later in 1965. Modern reviews in the Harvard Business Review continue to substantiate that managers who deliberately cultivate non-coercive influence deliver projects faster and retain key engineering talent longer than authoritarian peers.

To evaluate where your organizational influence originates, review these foundational texts and empirical studies:

Featured image by Ruxanda Photography on Pexels