How to deal with a colleague who is showing off my work as his own?

Question

The situation goes like this. A project in research lab involves programming, data analysis and writing reports. I have done most of the programming and data analysis on my own thus far. I shared these programs with a colleague who was helping me with testing. Fast forward 5 months, he now uses my code to perform analyses. He still works with data from my code but is trying to show it off to the boss as his work.

I have tried correcting the situation once by talking to him, but there seems to be no effect. Should I talk to my boss about this? If yes, how should I bring it up with him? If no, what other recourse should I take?

Answer 1

What I'm hearing is all about the other employee, but there's a greater perspective of the office as a whole to consider. The general goal of most workplaces is to function as a team and combine the efforts of the team and the organization into a successful end goal. There's a fine line between specialization of labor (his analysis, your code) and claiming undue credit for someone else's work. While your fellow employee's claims are certainly annoying, another part of the picture is the perspective of the boss and the way work flows in the team.

Incentives and Goals

First - make sure you're clear on the incentives and goals for your work - is this a case of he-who-presents-the-most-final-product wins? Or is it more about combining efforts - code, analysis, reports - where effort is regularly combined, so that any large and meaningful contribution is valued?

Ways to diagnose this:

• What activities are directly tied to any bonuses or incentives?
• Who has gotten rewarded or praised in the past? What actions get promotions? Who is held in high esteem by the boss?

Make sure your contributions are clear to the whole team by taking ownership

Don't just say "hey, I wrote that code" - take ownership of the code in a helpful and supportive way. When the colleague is going on and on in the team meeting about his great findings - ask him if the code base is working out for him? Are there any updates that should be made? Propose ways that the code base can be grown, since it's clearly something that is useful to more than one person. Given that you are the primary creator and the mind behind the key decisions in this area, your competence will shine through, and you'll be having a productive conversation.

This is a way of highlighting that something you made has now benefited two elements of the research - your own work and your colleague's.

Talking to the Boss

Yes, if you are concerned that your boss doesn't see the value of your creations because someone else is taking credit for your work, it's time to have a talk with the boss. A key element here is to get a sense of whether the boss understands that your code has serious value and took serious work that was yours and yours alone. Generally in a team the work of any team member should be available to colleagues for reuse - the organization paid for this work for the good of the organization, not the individual. But often that work isn't given much credit if it's not the major visible output of the team.

Generally it won't go well if you are simply passively asking the boss to recognize your work and to shut down the bragging of your colleague. But it is important to ask for:

• affirmation that your contribution to the research be recognized - including any insistence that is appropriate in crediting you in publications
• input on whether value is placed on the work you've done - in a software development shop, there is no doubt that the code has value. But when code is used as the means to an end (getting data for analysis and writing reports) - it can be important to get a sense of whether the organization values this work.

Taking ownership vs. Begging for Credit

Either way, it's communicating that you have done good work and provide valuable contributions to the team. Taking ownership in any venue is generally stronger way of communicating the value because it shows that you have vision, useful input, and you're not putting anyone else on the defensive. It sounds like this guy is doing work (analysis) that lends some degree of value - he didn't just carbon copy your work. So if you start pointing fingers, you start getting into a realm of judgements and defensiveness that may not work well for anyone.

But if you take ownership of your own work products and make them valueable to the team, you show a positive way to move forward and you highlight yourself and the work you do in a way that is hard to dispute.

Answer 2

I've had a few people to pull that in my experience.

The easiest technique for me as a manager is to sit down with everyone on the project team and start asking questions, going deeper and deeper until I understand who-did-what on the project.

If your supervisor isn't doing anything like that, he or she might have some insight based on what's happening in GitHub, TFS, or any other place your team might be recording who's-doing-what. Long term, and this might be beyond your control, having a concrete way to track projects at a task level is critical for finding and removing the dead weight that nearly every project team seems to accumulate over time.

But to answer your question directly, I would put a Visio together and do a system overview with your supervisor. Make sure you invite your colleague, but it should be clear as you step through the systems that you're the one in posession of the knowledge, you know how huge pieces of it work, and then you can (correctly) show how you're a great team player because it's allowed your colleague to continue doing productive things.

Highlight what you're doing in a constructive way. Documentation, a simple Visio, and knowledge sharing with other people on your team will show who-did-what and is a mile better than some other tactic that will likely come across as petty or personal.

Answer 3

Often when bosses hear 's/he stole my idea/work/credit' they just tune it out. If the two of you aren't getting along, keep it to yourselves. Often bosses know when someone is operating at the edge of credibility, typically because they can't explain how they got to where they are. You could mention that you're dissatisfied, but there isn't much point in doing much beyond that.

The original question sounds like your co-worker is using your data, adding layers of his own, producing an analysis, and insisting that this is his work only. This is a situation that invites a 'thesis defense' - ask him to explain to your boss every layer of evidence to support his results, and what he did exactly to get them. He may know his way around the data as well as you do, even if he didn't gather it. He may also not understand anything, and get defensive when asked to put his cards on the table.

If the software is subject to periodic revision, and you're the one creating the revisions, consider watermarking reports or otherwise altering the presentation in ways that the colleague can't control. If he can't explain to the boss how the watermark got there, then it's obvious that he doesn't code the solution.

A bit of mischief, which could backfire, would be to switch fonts in the headings depending on whose account the report is run under. This is a particularly good use of Comic Sans MS.

The general public may view academia as a bunch of professors that challenge students with hard problems, spend Saturdays reading old books, and fly off to conferences to discuss impenetrable topics. I recall reading a book one time from someone intended to be one of those professors, until he realized it was a snakepit of intrigue. There is no 'market' in the sense that customers positively reinforce good ideas - therefore it's a matter of peer review, publication, citations, salaries, and 'prestige'. Fights often last a lifetime and are extremely bitter. One side effect of this is that people either have to put up or shut up - if you can't explain how you got to where you are and no one can reproduce your results, you'll get hammered. Keyword search 'two dangerous tribes'.