11

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?

  • 6
    Related reading - this is another situation where gaining visibility can be hugely important. – enderland Nov 20 '13 at 3:05
  • 3
    Are you saying that the colleague is stating that he wrote all the tools? Or that the analysis, leveraging the tools you wrote, is his work? Is it possible that you never mentioned to the boss in the 5 months since you wrote it that you wrote the tool? It is pretty common in a research lab for one researcher to leverage tools written by someone else in the lab-- no reason to have multiple people writing code that does the same thing. – Justin Cave Nov 20 '13 at 3:08
  • 4
    Is it fair to say that you more concerned about your work not being recognized, than you are about your colleague being competitive? – user10911 Nov 20 '13 at 4:06
  • 1
    Learn to recognize your self celebrate even little achievements, talk about things you do .No body else will do it for you, and soon there will be an atmosphere where you will be recognized. – amar Nov 20 '13 at 4:35
  • 4
    Welcome to The Workplace knk! As I read it, you made code, he tested it, and continues to use it 5 months later. This seems like a success, not a problem. Could you edit your question to explain what the actual problem you're facing is? Is he pretending he wrote the code? Are you expecting him to give you credit every time he uses the code? – jmac Nov 20 '13 at 6:36
15
+50

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.

0

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.

-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'.

  • 1
    If this answer is going to have 3 downvotes, it should have a comment explaining why. – user10911 Nov 22 '13 at 10:35
  • 1
    I didn't downvote, but I can see where someone might think it's irresponsible to put things into the software that "prove" it's your work. And the last paragraph seems like a digression. – Amy Blankenship Nov 22 '13 at 18:04
  • @AmyBlankenship - 'Disclaimer - it could backfire' - in short, possible - but not recommended. This is a discussion of academic research. The OP doesn't seem to have quite yet grasped the nature of the environment. – Meredith Poor Nov 22 '13 at 20:51
  • Hm, I didn't necessarily assume all research labs are in academia, but you could well be right. – Amy Blankenship Nov 23 '13 at 3:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.