I worked with David Nyika during the 2020 Tokyo Olympics

Why I Earn 10x More Than Better Developers — Part 2: Understanding Internal Politics

This post last year is my most read of all time.

It’s been nearly a year and I decided to do a part 2 because I feel like I can contribute to the article with something that has been a revelation for me personally.

This tweet helps to articulate it.

Not a Medium member? Keep reading by clicking **here**.

It’s quite a profound thing to read. The seller and the buyer are the same team.

I think when you start a business or start to do sales you think you need to prove yourself and then you focus too much on your company, your team, your track record.

With time you start to realise that the people you are selling to typically have so much they need to overcome internally that you are one of the last things that they think about.

Let’s take a normal company.

There’s a Head of Marketing called Sarah. She’s been thinking about an AI project for six months. She’s read articles, she’s seen what competitors are doing, and she’s convinced this could be transformative for her team.

So she reaches out to you.

While on the surface this seems obvious, Sarah needs a product built, what you often find is that it is more complex than that.

What do I mean? Well the real thing is that Sarah needs to survive and people spend a huge amount of time just trying to survive, far more than I first thought.

• She needs to get budget approved by a CFO who thinks AI is overhyped.
• She needs to get buy-in from an IT department that will want to run their own security review.
• She has a peer in the executive team, a Head of Product called James, who pitched his own AI initiative last quarter and got knocked back and if Sarah’s project gets funded and his didn’t, that’s a political problem.

She also has a board meeting in eight weeks and if she can show early results, she’s in line for a promotion.

Conversely, if she doesn’t show results, she is going to get asked questions about her performance.

None of this has anything to do with your code.

All of it determines whether you get hired, how much you get paid, and whether the project actually succeeds.

Sales is more about icebergs than I first thought

I used to think that when a client reached out, the hard part was done. They’d found me, they wanted to work with me, now we just needed to agree on scope and price.

That is laughably wrong.

In most organisations, the person who contacts you has maybe 20% of the authority needed to actually make the project happen. The other 80% is scattered across finance, IT, legal, procurement, and whoever else has veto power that week.

Your contact is essentially a project manager for an internal sales campaign and they’re doing it on top of their actual job.

This is what Jen Abel means when she says the seller and the buyer are the same team. Your job is to help them sell internally, because if they can’t sell it inside their own building, your proposal is just a PDF that sits in someone’s inbox forever.

Also, I am often surprised by how often people are pushing things internally against resistance. They might be doing that because they are passionate about AI or really believe in making a difference.

The five internal obstacles your buyer faces

Once I started seeing the world this way, I noticed the same five blockers showing up over and over again.

1. The budget gatekeeper

Every organisation has someone whose entire identity is tied to saying no to spending. Usually a CFO or Finance Director. They don’t care about your wireframes. They care about whether this line item fits within the quarterly forecast and whether it sets a precedent for other departments to come asking for money.

What I do now: I ask my contact early on how their budget approval works. Who signs off? What thresholds trigger additional approval layers? Is there a difference between capex and opex in their world? I’ve had projects where restructuring a $60,000 engagement into three $20,000 phases made the difference between approval and rejection — because anything under $25,000 only needed one signature.

And also timing is extremely important. If your project lands in a different financial year then it’s often put in a new budget. A number of companies also set their budgets in advance. They might set them in March. That means if you are meeting them in November, then it’s not that long until they set budgets again and this will open new funding lines.

That’s the kind of thing a developer would never think to ask. And it’s worth thousands.

2. The IT veto

In larger organisations, IT has an informal veto over any technology project. They’ll want to know about security, data handling, infrastructure, integration with existing systems. Reasonable questions, all of them. The problem is timing. If IT gets brought in too late, they feel disrespected and become obstructive. If they get brought in too early, they can slow the whole thing down with requirements gathering before the project even has momentum.

What I do now: I help my contact figure out when to loop IT in and I prepare a one-page technical summary specifically for that conversation. It answers their questions before they ask them. My contact walks into that meeting looking prepared and competent. Remember it is your job to help your contact look good to all of their stakeholders, not just their direct report.

3. The rival stakeholder (beware of these)

This is the James problem from earlier. In every organisation, there’s someone who either wanted this project for themselves, pitched something similar that got rejected, or just doesn’t like the person who’s championing your project. Politics.

You cannot fix this. You can only be aware of it. When your contact mentions that “getting alignment” is taking a while, or that they need to “socialise the idea” first, this is what they mean. There’s a human being somewhere in the organisation who needs to be managed.

What I do now: I ask who else has a stake in this area. I ask who might feel threatened by the project. I ask what’s been tried before and why it didn’t work.

Often people are happy to explain or vent about potential hurdle they will face by someone internally. It’s as frustrating for them as it is for you.

4. Ugh procurement

Some organisations have procurement departments whose job it is to get three quotes for everything, drive down prices, and add six weeks to any timeline. If you’ve ever had a deal that felt certain and then went quiet for a month, procurement is probably what happened.

What I do now: I ask about procurement on the first call. “What does your process look like for engaging external partners?” If there’s a formal process, I want to know about it immediately so I can plan around it. Often I’ll suggest a smaller initial engagement that falls below the procurement threshold, deliver value fast, and then expand from there. The first project is a beachhead.

I love this timing chart by Jen.

5. The problem with presentations

This is the one that changed everything for me. Your buyer almost certainly has to present your proposal to someone else. A leadership team, a board, a steering committee. And they have to do that presentation themselves, with their own credibility on the line.

Most developers send a proposal and assume their work is done. The proposal then gets forwarded around, read out of context, misunderstood, and eventually someone asks a question that nobody in the room can answer. The project dies quietly.

What I do now: I help write the internal business case for my client. I build the slides for their board presentation. I create the one-page summary they can forward to the CFO. I structure the whole thing so that when Sarah walks into that boardroom, she looks like she’s done thorough due diligence and has a clear, low-risk plan.

I’m essentially doing her internal selling for her.

That is what Jen means by co-authorship.

A mindset of co-authorship

Read that tweet again. “How do we help you navigate this internally; pricing structure, invoicing, the highly-contextualised memo… it’s co-authorship.”

When I first read this, it crystallised something I’d been doing instinctively for a couple of years. The best client relationships I’ve ever had were ones where I stopped thinking of myself as a vendor and started thinking of myself as someone on their team.

That means:

I structure my invoices the way that makes their finance department happy, even if it’s annoying for me. If they need monthly invoicing against milestones instead of 50% upfront, fine. That friction is worth removing.

I write the memo that justifies the project in their language, referencing their strategic priorities, their KPIs, their board’s concerns. My contact can literally copy and paste it.

I time my deliverables around their internal calendar. If the board meets on the 15th, I make sure there’s something demonstrable by the 12th.

I give them the language to defend the project when someone challenges it.

• “What if it doesn’t work?” — here’s the answer.
• “Why this vendor?” — here’s the answer.
• “Can’t we do this in-house?” — here’s the answer.

An easy trick to start doing this: the org chart

The first thing you need to do is get an understanding of the org chart. It’s not a full mapping of the entire company but just the people related to your contact.

You ask them.

• Who is your direct report
• Who reports to you
• Who is your peer
• What are the key topline functions in your business?

The great thing about this exercise is that it gives you names. Names are very important, they allow you to start speaking specifically.

“Oh cool, so when we build this, does Margaret sign this off or does Harriet?”

“Who would be the internal owner of this project, once it’s complete, would be that be Jessica and her team?”

The org chart really help you here and speaking in plain English with their names is much better as that is how companies talk anyway. Clients will say Margaret they won’t say CMO. It’s a psychological thing that helps you to start speaking the same language as them.

Once you have the org chart you can then starting asking other questions.

“How does budget approval work in your organisation?”

This tells you who the real decision maker is and what constraints you’re working within.

“Has anything like this been tried before?”

This tells you about political landmines and historical context.

“Who else has a stake in this area?”

This tells you about rival stakeholders and potential allies. If it’s a big enough problem, then it is very random for a company to not have tried to at least solve it themselves or build prototypes and have people in silos building their own tools.

“When do you need to show results, and to whom?”

This tells you about their internal deadlines and presentation requirements.

If there is no internal pressure or incentive then this job won’t happen.

“What would make this a career win for you?”

This is the big one. Most people will pause when you ask this, because nobody asks them this. The answer tells you everything about how to position the project.

Everyone in the world wants to advance in the careers pretty much, it’s a natural trait of being human. It’s also a fun question as people start speaking from their emotive side rather than just logic.

These five questions take about thirty minutes. Sometimes they won’t know, this is actually quite common if this is a new tech project and your contact might be new to the role. It’s better for them to find out early. Again this is why thinking of co-authorship is important, your contact might be procuring things on their company for the first time so everything is learning for them as well.

How this impacts your pricing

Here’s the thing that might seem counterintuitive. When you start doing all of this:

• writing internal memos
• structuring invoices
• building board presentations
• navigating procurement

You are doing more work, and most of it isn’t coding.

So why does it result in higher fees?

Because you’ve made yourself essential to something much bigger than a codebase. You’re essential to your client’s internal success. And internal success is worth a lot more than a GitHub repository.

When Sarah gets the budget approved and the board nods along and the project launches smoothly and she gets her promotion — the value of that outcome to her and to the organisation is enormous. Your fee is a fraction of it.

When you’re just writing code, you’re competing with every developer on the planet and increasingly with AI tools that can do it faster. When you’re navigating internal politics and co-authoring the business case and managing the procurement process and building the board presentation, there is almost no competition. Most developers have no idea this world exists.

That’s where the 10x comes from.

Conclusion

Part 1 was about realising that clients buy more than code. They buy peace of mind, risk reduction, status enhancement, and time recovery.

Part 2 is about realising that your client’s biggest challenge is usually inside their own organisation. They have budgets to justify, colleagues to convince, boards to impress, and processes to navigate. When you help them with all of that, you become something much more valuable than a developer.

You become the person who makes things happen.

And that’s a very hard thing to replace.

Before you go

Subscribe to my free Substack newsletter because you get the following:

• A brand-new article for executives on Sunday that’s only posted on Substack.
• Links to every Medium post I’ve written in the past week
• Book recommendations every week for you to spend your Audible credits on