You Have Two Managers and Neither One Has Seen Half Your Work
A structural reason your stakeholders don't fully trust you yet, and the weekly update that fixed it for me.
Many years ago, I had two managers. Only one was official. My team, DataOps was engineering and I reported to the VP of Engineering. The analytics team kept changing hands until it settled under the head of data, who reported to the Chief Product Officer. We had two departments, two budgets, two sets of quarterly goals, and I answered to both of them whether anyone had written that down or not.
DataOps owned the infrastructure: ML infra, clickstream events, the data flow between systems, and the model review whenever we acquired a company.
BI owned the output: dashboards, the board pack, one shared definition of what the KPIs actually meant.
BI was my biggest stakeholder by volume. They could not ship a single number without the pipelines my team maintained. I ended up as the connection point between two senior leaders who each saw half of what I did.
This setup is comon in data orgs. Anytime engineering sits under R&D or platform and analytics reports to the business side, someone ends up standing in the middle, no mattar what the org chart shows. When that happens, you have two options.
Playing Defense Caps You At Senior
Option one is the one I see the most. Since I started coaching data engineers, I’ve talked to a handful of them stuck in exactly this setup, and most start the same way.
You get frustrated, and start wondering who this other person is to ask about their timelines, their priorities, or when you’re taking leave. You complain to your actual manager and ask them to be the proxy.
It feels justified in the moment, but it’s the wrong move.
Asking your manager to handle the comms for you tells the org that you can’t be trusted to prioritize your own work or manage a stakeholder relationship without a chaperone. Keep doing that and you cap out at senior, because the jump past senior depends on the exact skill you just outsourced.
Your stakeholders notice too, and they stop asking you directly, so they find a way around the data team entirely, but using a shadow spreadsheet or a self-service tool nobody vetted.
Treat It Like You Actually Report To Both
Option two is the one I took, mostly out of necessity. I reported my priorities, my progress, and my time off to both the VP of Engineering and the Head of BI, the same way I would have reported them to one manager. That meant a real report on what I was working on, what had shipped, what was at risk, and when I would be out.
This works because matrixed reporting lines split your visibility in half, and each manager sees a different, incomplete slice of what you do. Neither one has the full picture unless you build it yourself.
The VP of Engineering saw my roadmap, my asks, and how fast my team shipped. The BI Head saw whether the dashboards had fresh data. Neither saw the whole job, because I was the one doing it.
Everyone expected my team would work on their priorities and planned their roadmap according to this expectation. And this resulted in some overwork, a bit of context switch and a whole lot of stress.
Once I started reporting to both of them on purpose, they stopped guessing and started planning around me.
When you do that, you stop being the data team people route requests to, and you become the person both sides call before they make a decision that touches data. That’s the difference between a service provider and a strategic partner, and it doesn’t require a title change to happen.
That shift only sticks if the weekly update is simple enough to actually send.
The Weekly Habit That Makes It Work
Reporting to two managers only works if it costs you less time than avoiding it. I setup a weekly one to one with my second manager and shared my update so it would fit in 4 lines of text.
The Four-Line Format
Your report must be simple. The more time it takes you to prepare for this, the more likely you are to skip it:
Priorities this week
Progress since last update
Risks or blockers
Time off or availability
The One Rule
There is one rule keeps this from turning into two people pulling you in different directions.
Whoever owns the roadmap decides prioritization, and the other person get visibility.
In my case, when BI wanted something we didn’t have the time to do, that became a conversation between me and my actual manager, not something I negotiated ad hoc in a Slack thread.
I turned this into a one-page kit. It includes a worksheet for mapping who your other managers actually are, the exact weekly update template, and the two-sentence script for opening the arrangement.
The only way to download the worksheet is to upgrade now.
Final Thoughts
Org charts don’t really work for data teams we are cursed blessed with the opportunity to talk to anybody in the company, from individual contributors to the CEO.
Communication and management skills show up anywhere a stakeholder has real sway over your work without formal authority over your career, being it a vendor, a client, or a cross-functional peer who can veto your launch.
Treat the informal relationship like the formal one, and people stop wondering whether you can be trusted with the parts of the job that aren’t code. That’s really the other half of the job.
Until next time,
Yordan
PS: I started Data Gibberish to help tech experts who struggle with corporate politics and career blocks like this one. Upgrade today and get access to everything in the Premium Content Library.