"That's Not My Job" Is Killing Your Career
How retreating to job descriptions hurts your team - and your growth
The Slack notification pinged at 15:47 on a Thursday.
"Hey team, just discovered our client dashboard is showing last month's data. Anyone know who handles the refresh schedule?"
Sarah from Product typed first: "That's a data engineering thing."
Marcus from Engineering responded within seconds: "Actually, that dashboard is owned by Analytics."
Chen from Analytics chimed in: "We just visualise the data. The pipeline that feeds it is Engineering's responsibility."
Twenty minutes later, the thread had grown to 47 messages. Everyone had explained, in increasingly defensive detail, why fixing the dashboard wasn't their job. Meanwhile, the client (who had a board presentation the next morning) was still looking at stale data.
I've watched this scene play out countless times across different teams, different companies, different industries. The specifics change, but the pattern remains: a problem emerges in the space between job descriptions, and instead of someone stepping up to solve it, everyone steps back to protect their territory.
This isn't just about a broken dashboard or a frustrated client. It's about a mindset that's quietly poisoning data teams everywhere - the reflexive retreat to "that's not my job." It's a phrase that sounds reasonable in isolation but becomes toxic at scale. And if you've ever found yourself in one of these Slack threads, either as the person asking for help or as one of the defenders of your job description, you already know the damage it can do.
What you might not realise is how much this mentality is limiting not just your team's success, but your own career growth.
This is why hearing "that's not my job" is one of my biggest pet peeves to hear at work (with a few key caveats).
It's both a career-limiting move and the opposite of being a team player.
If you're fuming at the above and find yourself muttering "toxic workplace", I promise the article below is nuanced enough to bring your blood pressure down. If you're already nodding along, I hope this article will help you better advocate for the ways of working you're desperately trying to get in your team.
Why do people say 'it's not my job?'
I get where the comment is coming from. You were hired to do a job. You are being paid to do that job. Other responsibilities might fall outside your skill, comfort level, enjoyment, or seniority/payscale (either in that you don't think you're paid well enough to do them, or that you have risen above that work).
It's very reasonable for someone to say:
I want to have autonomy and choice over what work I do based on what I enjoy doing
I want to have appropriate training and experience before being trusted with certain tasks
I want to be compensated commensurately to my responsibilities
BUT often these reasonable expectations become roadblocks for your team and project.
Why "that's not my job" hurts both your team and career
If a certain task is not your job, but also not part of anyone else's job, then what do we do? By the logic of a "not my job" person, we just sit and wait until we can find someone whose job it is to do the thing.
Besides being a shitty way to work with your teammates (who often also do things that "aren't' their job" so that the team can win together), it's also an attitude that won't serve your professional growth.
A lot of the skills, experiences, and promotions that folks get come as a result of doing things that aren't strictly in their JD.
There's a few structural causes for why data teams in particular are especially prone to requiring folks to do things that aren't "their job":
Poor definition of D&A roles and responsibilities: Most data teams are incorrectly regarded by their organisations as a purely technical discipline. It's why you see Head of Data job descriptions requiring up-to-date Python and AWS skills, and why most orgs don't have someone doing the work of a Data Product Manager or Analytics Translator.
New specialisations emerge all the time: Compared to established fields like medicine, accounting, or engineering, the data profession is rather nascent, and new roles emerge as technology and ways of working advance.
Some examples:
Data Engineering wasn't a common role when the data scientist role was first introduced 10-15 years ago
Analytics Engineering came about partly as a result of tools like dbt
Machine Learning Engineering emerged to describe the data scientists focused on building and maintaining models in production
Data Product Management is seeing its rise as more and more organisations realise they need to (1) invest in understanding where the data team should direct its efforts (aka Discovery) and (2) treat their most important outputs as products
Unstable teams: I'm not a fan of it, but a lot of the time, data folks are staffed temporarily and moved around a lot. This means that where previously your job may have been X+Y, you might then join a bigger project where all you need to do is Y. And then after that you might need to do X+Y+Z. Maybe you were only hired with X+Y in mind, and nobody in your team was hired with expertise in Z. If the project is already underway and you don't have the time and/or budget to hire a specialist in Z, someone needs to step up and do it, or the project won't succeed.
As much as some responsibilities might be "not your job", it is equally likely that they are not not your job.
Why should I care?
Refusing to do the work will hurt your project and team
When everyone retreats to their job descriptions, work stops flowing. That dashboard refresh? It sits broken for days while emails ping back and forth about whose responsibility it "technically" is. Meanwhile, your team misses sprint goals, client relationships suffer, and stakeholders lose confidence in your data team's reliability.
I've seen entire projects derail because a two-hour task got stuck in a three-week game of responsibility hot potato. The irony? By the time you've spent hours in meetings arguing about whose job it is, someone could have just fixed it and moved on.
Refusing to do the work will also hurt your relationships with your team
Now, you might not care if your project or teammates suffer. You get paid either way. Fine.
Nothing breeds resentment faster than watching a teammate throw up their hands while everyone else scrambles to keep things moving. Your colleagues remember who steps up during crises and who hides behind job descriptions.
Sarah from Product will remember that when she desperately needed help cleaning messy data for a demo, Marcus from Engineering said "that's not my job" instead of spending 30 minutes helping her out. When Marcus later needs Sarah's help prioritising his feature requests, guess how enthusiastic she'll be?
A few years ago, I was on a team working on a thoroughly unpleasant project. A few months in, one of my teammates quit - and then proceeded to completely check out during their notice period. They were pissed at our employer, and the project (we all were). But the people who suffered as a result of them not doing anything for a month weren’t the big bosses, it was the rest of the team. None of us have forgotten about it.
Trust is built in moments like these, and "not my job" is trust's kryptonite.
Undermining your team's work will backfire on you also
Here's the thing about data teams: your success is completely intertwined. When the dashboard stays broken, it's not just "Analytics' problem" - it reflects poorly on the entire data function. Leadership doesn't distinguish between the data engineer who built the pipeline and the analyst who owns the dashboard when they're questioning why they invested in a data team that can't keep basic reporting working.
Your individual reputation rises and falls with your team's collective output. Being the person who lets the team fail while citing your job description doesn't protect your career - it tanks it along with everyone else's.
Doing things that aren't your job are good for career progression
The most valuable people I know became valuable by learning adjacent skills. The data scientist who learned enough front-end development to build better dashboards. The analyst who picked up enough data engineering to debug pipeline issues. The engineer who developed enough business acumen to suggest better data models.
These cross-functional skills don't just make you more effective at your current job - they make you promotable. Management roles require understanding multiple disciplines. Senior IC roles require being able to work across the entire data stack. And if you ever want to switch specializations or companies, having hands-on experience beats theoretical knowledge every time.
Plus, the projects that stretch you beyond your comfort zone often become your best stories in performance reviews and job interviews. "I stepped outside my role to solve X critical problem" demonstrates initiative, adaptability, and impact in ways that "I did exactly what my job description required" simply can't.
Caveats / in defence of "not my job"
[Caveat 1] Long-term vs short-term: If you're being continuously asked to do things that are far outside the remit of your role because your employer refuses to hire the right people & skills, that's different to becoming a blocker on a specific project or team sprint.
Of course if you're a data scientist being asked to magically find the time (and expertise) to do data engineering or BI development work for 12+ months now, then being unhappy about it isn't you being a bad team player - it's a resourcing issue. You should make your displeasure loud and clear to your people manager, the project manager, and if there's no signs of improvement, start looking for a new role (actually, start looking now, better to parallel-path these things than only start looking when you're past your breaking point)
BUT if your team's only BI developer is on holiday or recently left or the need for a front-end emerged more recently, and your project is on a tight deadline, AND you have the skills and bandwidth to do the dev work, 9 times out of 10 I think you should do it.
From a professional development point of view, learning/knowing how to do things that aren't strictly your job can be a great advantage too:
Experimentation & openness to learn: For example, there's lots of data scientists that realised data engineering was much more enjoyable and fulfilling to them.
Easier to transition to another role: Obviously, if you have the practical experience to show for it, even if you're not a fully-fledged specialist, you'll have an advantage over someone who just has some online certificates (or maybe, if you're applying for an internal move, they're a technical specialist but they lack the much more important domain & org knowledge you've built up)
Embracing change: Like it or not, the world is changing at an accelerating rate. Learning how to learn, and being able and willing to adapt professionally is going to be a must-have.
[Caveat 2] Wearing multiple hats doesn't mean working multiple jobs: I'm also not advocating for folks to overwork themselves and do two jobs at once. If your project is being managed poorly and needs 1.5x the FTEs it has, that's a management problem, and you might actually be better off refusing the extra work - otherwise management will think "see, they didn't need the extra FTEs after all" and keep causing you the same pain.
[Caveat 3] Org type & maturity matters a lot here: All of the above greatly depends on the size of the organisation. You'll need to be a lot more willing to wear multiple hats if you're in a startup (or a newly-formed team/department that's acting like a startup inside a larger org) than if you're part of a huge enterprise with entire teams of each specialist role. If you want to be doing just "your job" and hate other tasks, you'll be better off in larger, more mature teams than fast-growing, less-structured workplaces.
How can I balance being a team player while protecting my career (and sanity)?
Step 1: Run the time audit
Ask yourself: "Is this a quick task, or am I signing up for many months of doing work I don't like and/or aren't good at?"
If it's a few hours or days, just do it. If it's weeks or months, you need to have a conversation with your manager about resourcing, priorities, and what gets deprioritised from your actual role.
Step 2: Address the precedent upfront
Don't just silently accept extra work and hope it goes away. Say something like: "I'm happy to handle the dashboard refresh this time since it's urgent, but we should figure out a long-term solution so this doesn't become a bottleneck again."
This positions you as solution-oriented while setting boundaries for the future.
Step 3: Find your angle
Before saying yes, identify what's in it for you. Could this help you:
Learn a skill you've been wanting to develop?
Get visibility with stakeholders you normally don't work with?
Build a case for the promotion you've been seeking?
Better understand a part of the business that would make you more effective?
If there's no upside and it's not urgent, you have more grounds to push back.
Step 4: Drive the fix, not just the band-aid
When you step in, also advocate for the systemic solution. "I'll handle this pipeline issue today, but I think we need to discuss hiring a data engineer or restructuring our on-call rotation."
This shows leadership thinking, not just task completion.
Step 5: Know your organisational context
In a 50-person startup where you're the only data person? Wearing multiple hats is part of the deal. In a 500-person company with specialised teams? You should have more grounds to stick to your lane.
Match your approach to your environment's maturity and expectations.
The key is being strategic, not reflexive. Instead of automatically saying "not my job" or automatically saying yes, pause and evaluate: What's the cost, what's the benefit, and how can I handle this in a way that helps both the immediate situation and sets better precedents for the future?
In summary, being a good team player is a two-way dance
Data teams that embrace "not my job" thinking build silos. Data teams that embrace shared ownership build competitive advantages.
The companies winning with data aren't the ones with the most clearly defined job descriptions - they're the ones where people care more about outcomes than org charts.
The next time you see one of these situations unfold - whether it's in a Slack thread, a meeting, or a casual hallway conversation - you have a choice to make.
You can be the person who explains why it's not your problem. Sometimes that's the right call - when you're being exploited, when it's genuinely outside your capabilities, or when stepping in would set a destructive precedent. But those should be the exceptions, not your default response.
Most of the time, you can be the person who solves problems.
So pick your battles, and try to maximise your impact by being willing to do what it takes to get projects over the line. At the same time, you need to set yourself, your team, and your company up for long-term success by not burning out & stretching yourself too thin.
My advice? Assume “this is my job” as your default, not the other way around.
// In other news
🎙️ This week: We’ll be doing a LinkedIn live with Brian T. O’Neill
We’ll be talking about why so many technically brilliant data & AI projects fail to deliver real impact - and how product management and UX design can help bridge the gap. Brian is one of the leading voices in bringing UX thinking to data teams, so it’s a conversation you won’t want to miss.
This will be the first in a series of live conversations I’ll be running - I’m very excited.
We haven’t published the page on LinkedIn yet, but for now block the time on your diary (I left everything from my side a little too last minute…).
If you don’t want to miss it, drop a comment or DM me and I’ll make sure to send you a direct message with the registration link once it’s ready.
🍻 Next week: London Data PM meetup & BigDataLDN
I’ll be at BigDataLDN, one of Europe’s largest data conferences of the year. If you’re around, let me know! I mostly go to these things to catch up with people, so if you want to meet IRL, I’d love to connect.
AND we’ll have our monthly data product management meetup on 23 September - the evening before BigDataLDN. Special thanks to our friends at Harbr Data for sponsoring the evening.
🔗 Sign up for the meetup on Luma.
📚 Next month: I’m running another cohort of my course, ROI of Data & AI
After two fantastic public cohorts in January and July, I’ve decided to do a third cohort this year.
It’s a live course that’s designed for data product managers and data leaders who want to move beyond technical delivery and learn how to articulate, measure, and grow the business value of their work.
🔗 Apply to join us here.
🎁 Bonus: I’m giving all subscribers €100 off (use code ‘SUBSTACK’) when enrolling.
🌍 Thinking of starting an IRL meetup for data product managers?
Do you live somewhere with a non-zero number of fellow Data PMs, but without a DPM meetup? I want to help you change that!
I’ve already had folks reach out with an interest to start a local chapter in Dublin, Wroclaw, New York, and Melbourne. If you’re in one of those cities and want to help share the load, let me know! Hosting is much easier when you don’t need to attend 100% of meetups.
For more info, check out this article:
