manager-dot-dev Influence
Before Starting
Check for EM context first. If .agents/em-context.md exists, read it.
If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.
If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.
Response Style
Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
- State the likely diagnosis or recommendation first
- Ask at most 2-3 targeted questions only if the missing context changes the advice
- Give the next concrete action and, when useful, exact wording the manager can use
- Mention the relevant framework briefly, but do not explain every part of it
- Offer a deeper version only after the direct answer
How to Use This Skill
- Need a specific tactic for an upcoming conversation or meeting → The 5 Methods (pick the one that fits)
- Facing objections or resistance you anticipate → Label the Concern
- The other person isn't really engaging with your proposal → Get to "That's Right"
- Headcount request has been rejected or feels stuck → Getting Headcount: Arguing at the Right Layer
- Want to build long-term influence and be taken seriously → The 3 Levels of Positioning
- Wondering whether to play politics at all → Politics as a Skill
- Default approach to helping vs. extracting in relationships → Giver / Matcher / Taker
As an EM, you persuade constantly: executives to approve projects, leadership for more resources, reports to take on tasks, peers for cross-team help, hiring candidates to join, promotion panels to say yes. The list is endless.
5 methods that work specifically for engineering managers:
Default Response Shape
When helping with influence, produce a stakeholder plan:
- Decision target: what the user wants changed, approved, or believed.
- Stakeholder map: who needs to agree, who can block, and who is merely informed.
- Best influence move: choose the relevant method and explain why it fits.
- Message / script: wording for the next conversation or written ask.
- Risk: what could backfire politically or relationally.
If the user is trying to get headcount, start by checking alignment on problem and approach before arguing for people.
1. Nemawashi (Going Around the Roots)
Japanese gardening technique for transplanting large trees: gently loosen the roots one strand at a time before the big move.
When to use: Getting a calibration rating, pushing an initiative with multiple stakeholders who will all be in the same room.
How it works: Meet 1:1 with key stakeholders before the main meeting. Choose people with experience and influence. Tailor your case to what each person values — one values technical excellence, another values throughput, another values business impact. Hear their objections early and address concerns. By the time the main meeting happens, you've already built support and the discussion is far less contentious.
2. Decoy Pricing
A marketing technique: offer 3 options where one acts as a decoy to make your preferred option look like the obvious choice.
When to use: Headcount requests, asking a peer team for help.
How it works for headcount: Provide three options (Small, Medium, Large) with different outcomes for each, evaluated on dimensions your stakeholders care about (speed, quality, scope). Design it so the option you actually want looks like the best value compared to the others.
Reversed version: When asking a peer team's manager for help, the smallest option should be what you actually need — making it easy for them to say yes.
3. Reverse Psychology
Suggest the opposite of what you want, which makes the other person want to do what you really desire.
When to use: Hiring sell-calls with strong candidates; engineers who are resistant to trying new approaches.
How it works in hiring: List real reasons why the candidate shouldn't join your team. This attracts people who are drawn to challenges and want to prove themselves — exactly the people you want.
Example: "Don't join EngProd if you like to stay in your swim lane and wear only one hat."
4. LMDTFY (Let Me Decide That For You)
Reverse-delegation: you make the decision and tell the person they can take control back if they object. "Silence is consent."
When to use: Upward influence (getting your manager to delegate decision-making to you), and giving your reports autonomy on low-risk decisions.
How it works upward: "I intend to finalize this hire — let me know if you have concerns, otherwise I'll proceed." Over time, this trains your manager to trust your judgment on a category of decisions.
With reports: Teaches them to drive decisions forward while keeping oversight open. "I intend to deploy this release during my day — leave a message if you disagree."
5. Engineered Serendipity
Deliberately engineer a "coincidence" to create the right conditions for a hard conversation.
When to use: Cross-team friction that needs a real conversation but would never happen in a formal meeting.
How it works: Find out where/when the other person will be in an informal setting and arrange to be there too. Informal contexts lower defenses and allow real dialogue in a way that a scheduled meeting cannot. It doesn't guarantee results and doesn't force choices — it maximizes the chances of the right conversation happening.
Politics as a Skill
"Politics" in engineering has a bad reputation. It's worth reclaiming the word.
Politics, in this context, means: making the things you want to happen, actually happen. Understanding what each stakeholder cares about. Knowing how to frame a conversation for the right audience. Navigating resistance with the least friction rather than the most force.
Mediocre EMs resent politics. Effective EMs learn it. The skill is neutral — it can be used to advance good work or bad work. Your job is to use it to advance good work.
Giver / Matcher / Taker
From Adam Grant's Give and Take: people approach help and collaboration in one of three ways:
- Givers contribute without expecting anything back
- Matchers help when they expect to be helped in return
- Takers focus on what they can extract from relationships
The counterintuitive finding: Givers are both the lowest AND highest performers. The bottom of most industries is dominated by Givers (who give until they're exploited). The top is also dominated by Givers — because of two effects:
- Givers are constantly involved in complex problems (because people want their help), so they learn fastest
- When a Giver needs something, people line up to help them — because they've built genuine goodwill
Be a Giver. Set limits on exploitative relationships — but default to helping freely.
Label the Concern
From Never Split the Difference (Voss): before someone voices an objection, name it yourself.
"I imagine you're wondering why this is coming up now." "You might be concerned that this adds scope to an already full quarter." "I know this sounds expensive."
Labeling the concern disarms it. When people hear their unspoken worry named, they feel understood — which lowers resistance and opens them to the actual case you're making. If you don't label it and they raise it, you're defending; if you label it first, you're already on the same side.
The technique is especially effective in headcount conversations, architectural proposals, and any situation where you're asking for something the other person has reason to resist.
One warning: the label has to be accurate. A wrong label ("I imagine you think this is risky" when they're actually worried about ownership) creates friction instead of reducing it. When in doubt, keep the label vague: "I know there are concerns about this."
Get to "That's Right," Not "You're Right"
From Never Split the Difference (Voss): there's a critical difference between the two responses.
"You're right" means: you won the argument, I'll say what you want so we can move on. It signals capitulation, not genuine agreement. It almost never leads to real change.
"That's right" means: you've just summarized my situation so accurately that I feel understood. It's the response that comes when someone feels genuinely heard — and it opens them to persuasion.
How to get there: listen to what the other person is telling you about their world, then summarize it back to them so accurately that they can't help but agree. Not a paraphrase — a precise articulation of what they care about, what they're worried about, and what they're trying to achieve.
"So the concern is that if we invest in this now, we lose flexibility in Q3, and the Q3 roadmap already has more on it than the team can realistically handle."
When someone says "that's right" — that's when they're ready to actually engage with your proposal.
Getting Headcount: Arguing at the Right Layer
Most headcount requests fail not because they're wrong, but because they're arguing on the wrong layer. You're discussing whether to hire when the real disagreement is about something bigger.
Will Larson's hierarchy of alignment — work through these in order:
- Do we agree on the problem? e.g., "We're having too many incidents and it's hurting developer productivity and user trust." If leadership doesn't share this problem framing, no amount of headcount justification will land.
- Do we agree on the general approach? e.g., "We should invest in improving test coverage and on-call tooling." If they think the answer is process changes, not hiring, you're still misaligned.
- Do we agree the team is executing well today? Show metrics: incident trends over time, test coverage trajectory, developer survey data. If they don't believe the current team is capable, more of the same won't seem like the solution.
- Then ask for headcount. Only now is the specific request likely to land.
When a headcount request is rejected, diagnose which layer the disagreement is actually at. Arguing harder at layer 4 when the disagreement is at layer 1 wastes everyone's time and erodes credibility.
The 3 Levels of Positioning
How you and your team are positioned in people's minds determines how much friction you face when you need things: headcount, schedule flexibility, calibration outcomes, cross-team help.
Most EMs try to manage this by explaining themselves to leadership — clarifying challenges, defending the team, lowering expectations. That rarely works. A better approach is to rise to play in the same field.
Level 1: Known — Be Visible
Most EMs fail here. "Doing great work quietly" leaves 90% of the org not knowing you exist. Being known doesn't require networking events — it requires showing up in small ways consistently:
- Participate in cross-team projects and company-wide discussions
- React to and comment on announcements from other teams
- Ask relevant questions in meetings where you don't know everyone
- Have your team write release notes rather than you doing it
For your engineers: broadcasting their achievements publicly makes promotions easier. A developer who is known beyond engineering gets approvals faster — even from people who have never worked with them directly.
Level 2: Appreciated — Show Interest
The most underrated lever. Showing curiosity about someone's work and challenges makes you memorable and liked — and liking influences everything from scope negotiations to incident blame.
The new person rule: each week, have at least one conversation with someone you've never spoken to before. Not just from engineering. Start with something personal, then ask about their work and what's challenging for them.
Remember and follow up. Asking "How did that launch go?" two weeks after someone mentioned it is cheap and creates real goodwill. Knowing the names of people's spouses or children and asking specifically — not "how's the family?" — signals that you pay attention.
Level 3: Trusted — Help Others Achieve Their Goals
Trust is built by making people seem good and helping them succeed — not by explaining how good you are. Counterintuitively, the highest performers and most productive people in organizations tend to be the biggest givers.
To do this, you need to know what others care about. Level 2 gives you that. Then act on it:
- Support: Don't ignore their requests or redirect to product. When they bring a problem, engage — train their people, do some time in support if needed.
- QA: Be proactive about bug fixes; don't make them open tickets you ignore. Help them innovate with new tools.
- HR: Volunteer to help with learning & development processes, onboarding programs, or hiring process design. The time investment is small and the reciprocity is high.
- Finance: Do what they ask before the deadline. Everyone else is late. Find one operational problem they've always wanted solved and fix it — even a half-day is enough to create lasting goodwill.
The less visible a department is, the more they appreciate being helped. These relationships pay dividends disproportionate to the effort.
Dive Deeper
If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read references/sources.md for the full list of source articles (with links) and books.
Related Skills
managing-up— For influencing your own manager specifically: pulling, reliability, pushing back on decisionsworking-with-pm— PM relationship dynamics and getting alignment on roadmap prioritiesengineer-motivation— Level 1 positioning applies to your engineers too: help them become known