Leading engineering at a customer site when nobody reports to you

Picture your second week at a customer site. You find that the data team’s ETL job overwrites old records every night, so the agent you are building will have no history to answer users’ questions. Fixing it means that team has to change its pipeline, and nobody on that team reports to you.

Every FDE runs into this sooner or later. Palantir’s FDE job posting warns candidates up front that they will embed with customers, accept the mess that comes with it and share the consequences, and in return be given real ownership. But owning a product does not mean you can give orders to another company’s engineers.

That is why technical leadership at a customer site is a skill in its own right, and one you can practise. LeadDev sums it up: leading without authority is about influence, not power. What remains is where that influence comes from and how to use it.

Your authority is borrowed

Will Larson, writing about Staff-plus engineers, makes a point that fits FDEs closely. He argues that the organisational authority you hold is lent to you by someone more senior; it is not yours. To keep it, you have to stay tightly aligned with your sponsor, who is usually your manager.

Larson is talking about a sponsor inside your own company, but the idea extends to the customer side. There, the sponsor is usually the person who agreed to bring you in: an operations director, say, or a head of data.

When you say “this pipeline needs to change”, the data team goes along not because you are good, but because they believe their sponsor wants it.

This has a practical consequence. If you push a direction your sponsor has not agreed to, you are spending authority nobody gave you. It may work the first time. The second time, the engineers will go straight to their boss, and the borrowed authority will be taken back.

Credibility first, proposals second

Borrowed authority only opens the door. Whether the engineers then commit to the work depends on credibility. LeadDev advises building it by letting people see your knowledge and skills, and for an FDE the clearest way to show them is code that works.

Harper’s FDE job posting names this goal outright: embed with customers to build, deploy and earn technical trust. That trust comes first; only then do you ask them to change their architecture. In the first week, a small fix to the exact problem they are struggling with is worth more than ten slides of proposals.

Technical credibility alone is not enough, though. One analysis of the echo/delta model observes that a team focused only on relationships, without an engineering team that delivers, ends up shipping nothing, while an engineering team without demand and momentum from the customer builds impressive software that nobody at the customer needs.

An FDE has to hold both ends.

Worked example: letting the data team choose the pipeline fix

Back to the ETL job that overwrites data. Suppose you have already fixed a small bug in one of the data team’s internal tools and agreed with your sponsor that the agent needs historical data. Only now do you bring the problem into the meeting room.

LeadDev suggests a three-colour scale for laying out options: green means go ahead now, yellow means proceed with caution, red means stop and rethink. Instead of saying “you need to change the pipeline”, you put three options on the board:

Option	Colour	Main risk
Add a daily snapshot table, leave the existing job untouched	Green	Extra storage cost
Change the job to append instead of overwrite	Yellow	Reports reading the old table may break
Have the agent cache history on its own side	Red	Two sources of truth, data drift over time

The conversation might go like this. You: “The agent needs to know what a record’s value was last week. Here are three ways to do it. You know the system better than I do, so are these colours right?”

The data lead might reply: “The yellow option is actually green. Only two reports read that table.” At that point the decision is theirs.

This matches what Palantir asks of its FDEs: make architecture and design decisions together with other engineers, not impose them. You bring perspective and data; they bring knowledge of their own system.

Five steps to try yourself

1. Name the sponsor, and ask them directly what they are prioritising this quarter.
2. Ship something small that addresses a real pain point before you ask anyone to change anything.
3. Write the problem up as green–yellow–red options, each with a one-line risk.
4. Let the customer’s engineering team recolour each option.
5. Give regular progress updates to everyone involved, at every level.

The last step is the easiest to neglect. Palantir describes the FDE as the person who manages relationships from the users who work with the system every day up to the executives who make decisions, and LeadDev treats open, transparent and regular communication as essential.

Mistakes that cost FDEs their influence

The most common mistake is treating your title at your own company as authority. The customer’s engineers owe you nothing, and a proposal that opens with your company’s name sounds more like an imposition than a collaboration.

The second is going over the engineering team’s heads to their leadership. You may win the decision, but you lose the people who will have to run it after you leave.

The third is losing sight of your sponsor. Their priorities change while you keep pushing the old direction with authority that nobody stands behind any more. The last is doing only half the job: tending relationships without shipping, or shipping well without anyone needing it.

How to show employers this skill

If you are targeting FDE roles, read the lines in the job description that mention stakeholders, ownership or technical trust closely. That is where the employer is asking about this skill.

On your CV, don’t write “strong communication skills”. Describe a time you got a team that didn’t report to you to change a design: which options you put forward, which one they chose, and what happened after deployment. A story like that carries more weight than any adjective.

The hardest part of leading without authority is accepting that others will put their names on the decision. The more willing you are to give up that credit, the more likely someone will take ownership of the system you leave behind.