You're not supposed to be 'The boss'
The influence-authority trap & how to escape it
“You own the data strategy.” “You’re responsible for driving data adoption.” “It’s your job to make this organisation data-driven.”
And most data leaders hear it the same way: You should be in charge.
In product management, there’s an equally damaging one-liner that gets misunderstood the same way: “The product manager is the mini-CEO of their product.”
Both framings suggest the same thing: That your success depends on being the decision-maker. The person in charge. The boss.
That misunderstanding -thinking you should be the boss- creates one of two failure modes (which we’ll call anti-patterns)
In one, you’re frustrated that you don’t have the authority you think you deserve. In the other, you have authority but use it in ways that shut down the expertise you need most.
I’ve seen both anti-patterns play out across data product managers, heads of data, CDOs, and data leaders of all stripes. Both stem from the same fundamental misconception: That your job is to be in charge, rather than to facilitate great decisions.
Here’s what both look like, why they happen, and what to do instead.
Anti-pattern 1: You have zero authority (and you’re mad about it)
Your data engineers ignore your recommendations about the data platform. The business intelligence team builds dashboards without consulting you. Sales promises data products you’ve never discussed.
You get frustrated. “Why won’t anyone listen to me? I’m supposed to be driving the data strategy!”
This often happens when you’re new to the role - especially if you’re coming from a position where you did have authority. Maybe you were a senior data scientist whose technical recommendations got implemented. Maybe you were a data engineer who made architectural decisions. Maybe you were an analyst whose insights drove business changes.
Or you’re a Head of Data or CDO without clear authority. You’re “responsible” for data quality, data governance, the data platform - but engineering doesn’t report to you. The business teams don’t have to use what you build. You’re accountable without authority.
Or you see “manager” in your title and assume it means what it says. Manager. That means you manage people, right? You’re in charge of something?
So you try to establish that authority.
Week one, you’re more assertive in meetings. Week two, you start sending detailed emails outlining your decisions (that nobody reads). Week three, you escalate to your manager or skip-level: “Can you help me establish more authority with the teams?”
You introduce more “process” and “governance” to force people to include you. You create approval workflows. You require sign-offs on data architecture decisions. You insist on being in every meeting where data strategy might come up.
You’re doing all of this because you think the problem is that people don’t respect your authority. If only they understood you’re supposed to be in charge, they’d listen.
But the teams start working around you.
You find out about the new ML pipeline after it’s been deployed. The BI team and their stakeholders solved a reporting problem together and didn’t think to tell you. Your 1:1s become status updates rather than strategy discussions. You’re CC’d on decisions instead of being asked for input. Business teams hire their own data analysts/scientists. Leadership brings in an external consultancy instead of giving your team the work for the high-visibility project.
The more you try to assert authority you don’t have, the less influence you actually build.
In short: You become a bottleneck to route around, not a leader to collaborate with.
(And they’re right to try and work around you - or at least I can’t blame them)
Anti-pattern 2: You have all the authority (and you’re using it badly)
Your org structure gives you authority. Maybe you’re a CDO with a full data organisation reporting to you. Maybe you’re a Head of Data with engineers, analysts, and scientists on your team. Maybe you’re a data product manager whose technical team can’t ship without your approval.
You think: “Finally! This is how it should be. I’m in charge - I make the calls.”
People do exactly what you tell them to. Requirements get implemented to the letter. Nobody pushes back.
And somehow, the results still don’t follow.
Here’s what this looks like in practice:
You make unilateral technical decisions without consulting your leads. You decide the data platform should use technology X because you read about it at a conference, missing that your senior data engineer knows it won’t integrate well with your existing systems. You mandate a particular approach to data modeling because it’s “best practice,” ignoring that your data architect understands the specific constraints of your domain.
You dismiss feedback from the business because being “data-driven” means the data team knows best, right? The sales team stops telling you what customers are actually asking for. Finance stops explaining why certain metrics matter to the business. You build technically sound solutions that nobody uses.
You treat domain experts like order-takers rather than collaborators. The data scientist who’s been working in this industry for 10 years has an idea about how to improve the model, but you’ve already decided the approach. They shrug and implement your way, knowing it won’t work as well.
You override your BI lead’s dashboard design because you “know what users want.” You tell the data engineer which indexes to create. You set priorities without understanding what technical dependencies exist or what’s actually blocking value delivery.
Then you wonder why nobody seems engaged. Why people don’t bring ideas to you anymore. Why they nod along in meetings but don’t seem excited about what you’re building.
That’s because your team has stopped thinking. They’ve become order-takers.
The data engineer who could’ve spotted a fatal flaw in your approach stayed quiet. The analyst who had a better way to present insights didn’t share it. The data scientist who knows the domain better than you just nodded along.
You’ve optimised for compliance, not for outcomes.
Both anti-patterns are wrong
Both stem from the same root: You think you should be the boss.
In Anti-pattern 1, you realise you’re not actually the boss, get frustrated, and try to force authority you don’t have. You focus on building scaffolding (process, hierarchy, approvals) instead of building relationships.
In Anti-pattern 2, you act like a stereotypical 1980s movie boss - the kind who barks orders and doesn’t care if anyone agrees. You think having authority means you should use it to direct everyone.
Here’s the thing: When a CEO makes the mistake of conflating their authority for influence, they can usually force compliance through formal authority (even if it’s bad leadership). When a data leader makes this mistake in Anti-pattern 1, you just get ignored. When you make it in Anti-pattern 2, you get compliance without commitment.
Neither gets you what you actually need: A team and organisation that’s genuinely aligned around solving the right problems in the right way.
They both treat influence as a power dynamic rather than a collaboration model. You’re either fighting for power you don’t have, or wielding power in a way that shuts down the very expertise you need to succeed.
What real influence actually looks like
Real influence isn’t about having authority or not having it. It’s about creating an environment where the best ideas win, regardless of where they come from.
The “mini-CEO” advice is actually quite good - if you understand that great CEOs are facilitators, synthesisers, and relationship-builders first.
They:
Create alignment around shared goals. Instead of telling the team what to build, you help everyone understand why you’re building it and what success looks like. Your data engineer isn’t just “implementing a pipeline” - they understand they’re enabling sales teams to respond to leads 10x faster, and suddenly they’re spotting optimisation opportunities you never would have thought of.
Ask “dumb” questions. “What am I missing?” “What would make this fail?” “Who else should we talk to?” You’re not trying to prove you’re the smartest person in the room. You’re trying to extract the collective intelligence of everyone around you.
Help teams understand trade-offs. When engineering wants to rebuild the entire data platform and the business wants three new dashboards by next week, you don’t just pick a side. You don’t dictate the answer. You help both sides see the constraints the other is working under, and facilitate a conversation about what you can actually achieve.
You create space where your technical leads feel comfortable pushing back on a bad idea. Where you feel comfortable being wrong. Where everyone understands the “why” well enough that they can spot problems you didn’t see.
This is especially critical for data leaders
Your data scientists understand the math better than you. Your data engineers know the systems better. Your business stakeholders know their domain better.
If you’re not creating space for all of that expertise to surface, you’re building with one hand tied behind your back.
I’ve seen data products fail because the leader insisted on an ML solution without understanding that the data engineer knew the required data wasn’t actually available (and a non-ML approach would’ve worked fine). I’ve seen dashboards get built to spec that nobody uses because the leader didn’t involve the actual users in the design process - just their VP.
The data scientist who could’ve spotted a fatal flaw in your approach stayed quiet because you’ve made it clear you’re not interested in being challenged. The business stakeholder who knows their team will never adopt this tool doesn’t speak up because you’ve positioned yourself as the expert.
Your job isn’t to be the boss of your data strategy. It’s to be the person who helps everyone else make better decisions about it.
(btw, Brian T. O’Neill and I spent an hour on the problem of “building data products no one uses” and how to prevent that problem)
What this looks like when you get it right
You know you’re doing this well when:
Your technical leads proactively flag concerns before they become problems, because they trust you won’t shoot the messenger
Your analysts and BI developers bring you problems, not just solutions waiting for your approval - they see you as a thought partner, not a gatekeeper
Business stakeholders include you in early conversations because they trust your judgment about what’s possible
Decisions get made faster because everyone understands the “why” and can make calls independently
People volunteer ideas in meetings instead of waiting to be asked
When you’re wrong (and you will be), someone feels comfortable saying so
This is influence through collaboration, not influence through authority (or lack thereof).
Because at the end of the day, whether you’re a data product manager, head of data, CDO, or CEO - facilitating great decisions beats making all the decisions yourself.
Besides, who wants to be a mini-anything? 😆
Want to get better at this?
This is hard to unpack in a newsletter because it’s deeply contextual. The tactics that work when you’re new to an organisation are different from what works when you’ve already lost credibility. The approach when you have formal authority is different from when you don’t.
Which is exactly why next week, I’m doing a webinar with Clare Kitching (ex-McKinsey Associate Partner, now an independent consultant) on how to influence effectively as a data leader, regardless of your org structure.
Register to join on LinkedIn. We’ll also stream (and take questions from) YouTube and Substack, if you prefer those to LinkedIn. And we’ll record it if you can’t make it live (but if you can, do join live - you probably won’t watch the recording anyway 😆)
Shameless plug: Come learn how to build influence with my 3-week training+coaching programme
If you want to dive even deeper into building influence and demonstrating value (and work with me directly in group & 1:1 sessions), I’m running one last cohort of the ROI of Data & AI course this month.
We’ll cover how to quantify and communicate the value of your data products, get buy-in from stakeholders, and build the credibility that makes influence easier. Because influence is a lot easier when you can point to concrete outcomes you’ve driven.
Applications close on October 7, and I’m planning to stop offering this iteration of the programme going forward. There’ll be a version of it in 2026 for sure - but it’ll be slimmer and less comprehensive.
If you’re interested, apply here before the 7th. And if you’re not 100% sure about it, apply anyway - the next step is for us to have a 15-30’ call to go over any questions (and make sure you’re a good fit for it).
If you found this article useful, here’s a couple other articles that run along the same theme:
