12

I recently moved from Team A to Team B at my company. These two teams are not remotely in the same lines of work, outside of the fact they both exist within the same company.

Right before I left Team A, a new member joined. In my last few days with the team, I was tasked with getting him up to speed with the team's code base, basically all of which I wrote myself.

I have since moved on to Team B, but the guy from Team A continues to ask me questions about the code and come to me whenever there's a bug.

I was more than willing to help at first - to smooth his transition - but now his requests are annoying and distracting from the work I'm doing with Team B. Part of me wants to tell him to figure it out on his own, as I'm no longer part of that team, but the other part of me feels a bit obligated to help him, since I wrote the whole project myself.

Team A is no longer paying me, so I don't think I should continue helping them out -- but I'm not "obligated" to, am I?

7
  • 15
    It's a shame that your code is not self-explanatory to new member, whether this reflects on your code, on new member, or on some combination of those. But this is reality, not the ideal world of software written and maintained only by insightful, experienced geniuses, but by people like us. – MickeyfAgain_BeforeExitOfSO Jan 30 '17 at 16:41
  • @mickeyf One does not need to be a genius to document one’s code and design. This question demonstrates exactly why one should. – VGR Jan 30 '17 at 18:23
  • 1
    It is time to push your former Team A kouhai out of the nest and let him soar alone. – Mindwin Jan 30 '17 at 18:27
  • @mickeyf I don't think it's a matter of my code not being self-explanatory to a new member. Every line is commented well and I have even written step-by-step instructions on how to navigate the codebase. The issue seems to be that the new guy doesn't want to spend any time getting acclimated with the code -- he would rather I debugged everything every time he deviates from the very clear instructions I left. He would rather that I debug why he's getting a KeyError instead of looking it up for himself. – blacksite Jan 30 '17 at 18:32
  • 1
    There are some really good answers below, and it's true that it's up to the company and your managers and you should really be asking them. That said, one thing that I've done before escalating things to that level, is to introduce a delay on the responses. An email with "I'm busy with my work for Team B, but should have a chance to look at it tomorrow" can give them some incentive to spend some time looking into it themselves today, instead of turning to you just because it's easier and faster. – A C Jan 30 '17 at 19:24
69

Talk to your manager. Explain that the frequent interruptions from Team A are affecting your productivity, and ask your manager how they would like you to deal with this. At that point, there are pretty much two options:

  • Your manager tells you that it's important that you keep helping Team A. So you do that.
  • Your manager tells you that it's more important that you concentrate on your work with Team B. You can now redirect your colleague on Team A by saying "My manager has asked me to concentrate on my work here" - at which point it probably becomes a discussion between the manager of Team A and your manager.

As an aside, note that neither Team A nor Team B are paying you. The company is paying you, and you are obligated to do what the company asks you to do, not just work on stuff for Team B because that's what you want to do.

7
  • 26
    +1 the decision is not yours, and it's not the stack's either. It's up to your management to sort it out and to make decisions. – gazzz0x2z Jan 30 '17 at 15:30
  • 12
    +1 for pointing out that it's the COMPANY, not the team signing the paychecks. I would just add that refusing to help outright, without consulting management earns one the label of "problem" employee. – Old_Lamplighter Jan 30 '17 at 15:35
  • 4
    +1 for the first sentence, which is the key. Allocation of resources between teams is a management responsibility. – Patricia Shanahan Jan 30 '17 at 16:05
  • 13
    While it is true that the company is paying you, some companies assign budgets to teams to cover costs of employees and internal infrastructure etc. In this case, he would be spending his time that is paid for by Team B to help Team A without Team A spending anything, even if the money does all come from the company. – DavidTheWin Jan 30 '17 at 16:45
  • +1 if your manager tells you that you are obligated to help, then you are obligated to help. – WorkerDrone Jan 30 '17 at 17:21
8

I concur with Phillip Kendall's answer, but wish to supplement it.

You should have the requests elevated to the manager of Team A, sent to the manager of Team B, and then sent back to you.

This serves two purposes:

  1. It will make the new employee seriously try before just asking you "out of reflex." You have made it too easy for him to ask you directly.
  2. It will keep both managers informed of the situation. Manager B cannot know your amount of resource drain if he isn't aware of the requests, and Manager A cannot know the skill level of the new employee if he is getting help from you without his knowledge.

Nothing to be difficult or passive-aggressive, but it isn't fair to you or either manager to be doing this without their knowledge.

3
  • I like point 1 but I would attempt to be subtle about it. For a fairly simple issue, make him explain the problem to you until he figures it out. If he wants to know what a section of code does, tell him you forgot and go over it together.. The most important thing is that EVERYTHING that he doesn't understand directly should be changed, either re-written or commented. Having someone else ask questions about your code is by far the best way to improve it. Remember the problems he had and consider them in your future work. Consider this a fantastic opportunity to improve! – Bill K Jan 30 '17 at 18:18
  • This is correct but (as Manager B) I've tended to find it extremely difficult to implement/enforce. – Lightness Races in Orbit Jan 30 '17 at 18:31
  • @LightnessRacesinOrbit - Hey, if this was easy, EVERYBODY would do it. :) – Wesley Long Jan 30 '17 at 19:26
2

I wholly agree with Philip Kendall's answer, and I would like to add an alternative approach to implement his solution.

In your status report to team B manager, report the estimated time to support team A and highlight how it would affect your team B tasks.

"Task Foo takes me two weeks of effort, but I expect about 50% time spent supporting team A's code walkthrough, so I will be done in 4 weeks. If you think that is an issue, I would need some help to reduce my involvement with team A."

Two things could happen:

  1. Team B manager is okay with that, perhaps because team A manager has already explained the situation to him.
  2. Team B manager realizes the problem and then he has to figure out how to fix the problem and instruct you accordingly.

The benefit of this approach is the manager doesn't think, "Oh, I see, he hated the team A work so much that he is complaining about having to continue supporting it." (By the way, the tone of the question posted here totally suggests that.)

Instead it makes you sound like a responsible professional who doesn't just drop the ball and go home when the bell rings. You make it clear that you are concerned about the impact to team B, while at the same time, you continue to support your past teams. Demonstrating this attitude would be beneficial if/when you want to move from team B to team C in future.

Moreoever, telling the manager that you don't want to support team A carries a serious risk of losing face if the manager already knew about it. It is not a very comfortable situation to be in if the manager responds with "I am afraid you will have to continue supporting team A."

0

This all depends on the company and policy.

When moving between teams it was common for us to work out some sort of agreement as to what your duties are to the old team. Something along the lines of - weeks 1-4 you can devote 15 hours/week; weeks 5-9 5 hours/week and after that as needed with your current managers OK.

0

This is a good question, as it touches many aspects of our day jobs as programmers. What's important here, is that both teams work for the same organization. Unless your workplace is corrupt, you're all "on the same ship", and you should keep afloat as an organization and not as individual teams. From that perspective, the request to continue assisting team A ensures that they will not drown.

To get back to your personal concerns: it's hard to remain focused, but it's harder if you don't know what you're expected to do, and what you'll be judged by. If you feel peoples' expectations (yours, team A's, your managers') cannot be met, you can, and perhaps should, bring this up with the people responsible for that. Regardless of their job titles, they're usually the folks in charge of finances and scheduling. It's imperative NOT to complain, but to bring this up as a question, and to assume everybody is trying to do their best. Maybe team A needs more assistance than the schedulers predicted, and team A decided to ask for this themselves without including a 'planning' person. While this style of direct communication between teams is fine in many organizations, the responsibility to notify the 'planners' of potential delays lies with the teams.

Once the 'planning' folks are aware of the high demand of both teams, they can decide what is best on a larger scale of things; depending on which client pays more, deadlines, and the responsibilities they think team members should take on, they can make a decision that benefits the organization most. If all goes well, you should have a much clearer idea of what your employer would like you to do, and it'll be much less stressful to meet these expectations. Do keep in mind that, even if you no longer like the code team A has to work with, it's reasonable for your employer to ask you to remain involved for a while longer. If it helps, you can consider this a personal challenge in mentoring/training, rather than developing your technical skills.

-1

This is a judgement call with a few possible options, based on what you know about the company and each group. You certainly could ask your managers to clarify exactly how much time you can spend on Team A tasks. But it may be beneficial to show management that you are capable of handling this sort of minor conflict yourself.

It is often beneficial to do some of this sort of help for other groups within the company informally. It spreads your reputation as someone willing to help others, which tends to make other people more willing to help you without requiring a lot of time-consuming formal process. But exactly how much to help can be tricky, and you have to be willing to push back on these sorts of things if you think they're interfering with your primary tasks. You don't want a reputation as someone who will do others' work for them either.

You are perfectly within your rights to tell your colleague from Team A no, or to give him a few small pointers and say he's going to need to figure out the rest on his own. You could also put his requests at the bottom of your priority list, wait a while to respond, give short answers, tell him that you're busy with your Team B tasks, that sort of thing. Here, you're essentially putting the onus on him to either figure it out himself, or go to management himself about his lack of ability to do his job.

Not the answer you're looking for? Browse other questions tagged .