7

I have a manager who has assigned another coworker in my team to help me with onboarding and creating a few projects for me to work on. These are development projects that the coworker seems to suggest his team needs help on because they do not have time for development and need me as a dedicated person to help them code. The problem is that he has repeatedly not kept his promise to dedicate time to do provide assistance (in order for me to help him.)

Over the past few months, this coworker has occasionally (once a month only) met up with me to discuss the projects, but most of the times he's postponed meetings or ignored them completely. The current situation is pretty bad. He previously gave me some instructions to work on a tool, and after I finished it in a few weeks he promised me he would look over the tool, provide a testing environment, and test it with me. The problem is that he has postponed to do this over 6 times in the past couple months even though each time he has promised he'd find some time, and has a way of sounding like it's actually going to happen.

His explanations and/or excuses are that he is busy or has some random requests to fill and I always respect his words (he is in the build and release team), However, I am starting to doubt this, because as I started to pay attention over the past few weeks, he usually often is not at his desk or he leaves early.

The easiest solution to a problem is to not have to solve it. I can probably go to our mutual boss/manager and ask me to be assigned to some other projects. He's pretty flexible with what allowing me to move around. But before I take that route, and bring it up, I want to know what I can do to possibly salvage this existing arrangement. The coworker seems like a nice guy, but has a bad habit of making unfulfilled promises. I don't want to jeopardize the relationship if it can be fixed, because he can potentially provide me a lot of interesting projects that I can work on. However, none of this will be possible, if he doesn't make time to work with me.

As a side note: I'm a relatively new employee (2 years) versus he (10 years), and I was hired out of college.

How can I get my coworker to meet with me and give me feedback on the projects he's assigned me in a constructive, positive manner?

Thanks.

  • Not sure why I got a thumbs down. A comment would be appreciated. – CareerQuestions Jul 10 '13 at 1:47
  • Generally "what do you think?" is not really answerable or a good format for this site. Are you looking for how to get the information from the coworker? How to get around needing the coworker? It sounds like you are saying, "this sucks" without looking for some sort of resolution. – enderland Jul 10 '13 at 2:35
  • 2
    Hi CareerQuestions, welcome to The Workplace. We're a Q&A site, and the best questions are those that are clear in terms of what your problem is and what your question is. Discussion-oriented "advice" type questions don't fit our site too well. I edited your post with what I think you're trying to ask. I fixed the title and put the question in bold at the bottom. Please feel free to edit further, keeping in mind Q&A, if I've missed something. Good luck and welcome to the community! :) – jmort253 Jul 10 '13 at 6:22
  • If he needs to leave early frequently for a personal reason, he really may not have time for you. I suggest you discuss this with your manager and let him prioritize your coworker and your time! – Thorbjørn Ravn Andersen Jul 11 '13 at 8:49
10

The situation you're describing goes on all the time. Basically the reason people need coding help is that they're so busy they can't unglue their nose from the monitor.

To the maximum extent possible, you will need to 'hack this project'. In short, if someone intends for you to help them, but they're not giving you any direction, see how much you can find out without bothering anyone. This could include reviewing all project documentation (if you can get at it), any source code, database objects (tables, stored procedures, etc.), and running any existing builds. If other people in the group are willing to talk, see what they can tell you. Even better is if you can sit in on relevant meetings.

If you're unfamiliar with the development environment, this will raise questions in a hurry: you will see stuff you don't recognize. Track it down - figure out what it means. The analogy is you're learning a foreign language, you may know a few words but don't recognize the idioms. Pretty soon you'll be able to get at least a dim idea of where they are and what they're trying to do.

I had a friend that had been promised stuff like this, and he waited for someone to come around and tutor him on company time. He would tell me he would show up at work on some days and browse the internet, and spend other days on actual tasks. I could tell this was going to lead to a layoff, and when it happened I rather forcefully asserted that he needed to learn programming from scratch (he had done some embedded controller assembly in the 1980s, but that was it). Eighteen months later he was still out of work, and would go to job fairs where interviewer after interviewer asked him what he knew about PHP, JavaScript, Oracle, Java, etc.

Don't spend a second waiting for someone else to help you out. You're lucky if you get it, but don't expect it.

2

Have you had an honest conversation with this person? Explain the issue you face, and try to work out a solution between the two of you. If this fails, you have to take a good look at your situation. Are you late on projects because he fails to provide input and are getting flak for not doing your job? In that case your job could be on the line, and I would take it a step up in the hierarchy to protect yourself.

If you still manage to keep everyone happy with the work you do and the speed at which you do it, you could just accept the situation for what it is, and deal with it by basically doing what @MeredithPoor suggested: work hard at learning the things yourself that he should be helping you with.

There is a downside to not making this situation clear to your boss. Let's say you build something, and send it off to a client. It turns out that there was a serious error in there which was extremely hard to spot on your own, and which your more experienced colleague would have spotted and made you aware of. An unhappy client goes to your boss, and he goes to you. Stating at such a late stage that you should have had more help might not cut it at that stage. I'm not saying that you should go to your boss to force the other guy to help you, but I could be beneficial to make your boss aware of the situation using a phrase like: 'I'm ok working like this, although I would have expected more input from person X. However, I would still prefer more input from person X as it could prevent me from reinventing the wheel.'

2

One of the things we are missing in this conversation is what your manager's expectations are, and whether you are getting any feedback from him/her about how your projects are going. You haven't mentioned whether or not there are deadlines that you are pressured about, etc.

It seems like you don't know what else is going on in your group's workload that may have a much higher priority than your current project(s).

Perhaps it is time to ask a couple of specific questions of your manager, in a calm way that does not point the finger at your colleague who is postponing working with you, and might explain where your projects are in the bigger picture of the department.

Questions/Statements like:

  1. It seems like (coworkerName) is extremely busy right now. I don't want to interrupt him/her with extra questions, or prevent us from working on the highest priorities. Just so I understand, where is (my project name) in our current priority list?

  2. Can you suggest anyone else whom I should or shouldn't approach if I am looking for answers and (coworkerName) is busy? I don't want to spend hours researching on the net if a simple answer is available, but I don't want to upset my coworkers. How do you suggest I balance efficiency while trying to not be underfoot?

Sometimes as developers we tend to focus a little too much on the small details of a situation, or the requirements as we originally heard them, and not ask for more context. I think if you ask a few small questions (face to face, or by phone, rather than using electronic means, if at all possible) for more context, you will get a LOT more information than you would just sending emails or Outlook meeting requests.

1

Certainly taking it to your manager is a valid option, but I think you have some other options available before you try to make this your manager's problem. However, it is appropriate to keep your manager appraised of the situation. Privately in a 1-on-1, I'd mention that this coworker has been an impediment so far, and why, but I think you can also mention that you're taking some active steps yourself to keep things moving.

Here's some tricks I'd use.

1 Have a list

Sounds like there's more than one project that this coworker needs help with. Write up the list of everything you've heard of, and prioritize it as best you can. Vet the list both with the coworker and the manager - a group email should be fine.

2 - Clarify dependancies

In the list, clarify any you/coworker related dependencies at a high level For example:

  • write code for test tool - you
  • provide test environment - coworker
  • install code on environment - you?
  • provide feedback on test tool usefulness and needed fixes - coworker
  • provide updates - you Project = DONE

If you have more than 5 steps for an objective, it's probably too detailed. It just needs to be clear who is doing what, in what order and in words the boss as well as the coworker can understand. If it's a repeatable pattern, say so - for example, the list above is something that works on just about any project or feature in most software teams, replace "Test tool" with virtually any other type of code based development and you're list is probably accurate.

Share the list with the coworker and the manager. This makes the coworker accountable not just to you, but to management. If you've labeled a step wrong (perhaps you should know how to setup the test environment... perhaps he should test the installation of the feature...) - either he should step up and point it out, or the manager should.

3 - Silence = Agreement

Particularly in the case of dependandancies, don't write an open ended email. Write a time deadline driven message with a clear description of what will happen if a response is not received.

Example:

"Here's the list of tasks associated with our top priority objectives. Please take a look at the assignments and let me know if anything is missing or incorrect. I want to start the work by the end of the week, so please let me know by Wednesday. If I don't hear from you on Wednesday, I'll assume we're good to proceed and I'll start on my end of the work."

Thing to avoid:

"Here's my take on the list of tasks. I'm not really sure if you agree. Please let me know. I'll wait to hear from you before proceeding."

This would be a fine approach if you were talking to a customer or a person with authority over you or the project. For example, you can't write to a customer and say "I'm going to randomly do work for you and then send you a bill, if you don't tell me 'no' by tomorrow"... no matter how much you might like to. :) But where you are all tasked with the same goal, it's OK to say "I'm going to do what I understand to be my responsibility as quickly and efficiently as I can - so that you can do your end when you have time".

4 - Provide status

Often the original agreed upon list from step 2 is good enough. Work in a way that is kind to people who are busy, and don't make lots of words. A quick way is to take the original list and mark it up as follows:

  • write code for test tool - you - STATUS = DONE
  • provide test environment - coworker - STATUS = WAITING
  • install code on environment - you? - STATUS = BLOCKED
  • provide feedback on test tool usefulness and needed fixes - coworker - STATUS = BLOCKED
  • provide updates - you - STATUS = BLOCKED Project = Current status = 20%

If you've got a number of objectives, just move on to the next unblocked objective. Keep piling 'em up. Scheduling a meeting or promising to schedule a meeting does not count as reportable progress.

Again, CC the boss to keep him in the loop.

When you run out of tasks you can do yourself, it's time to go to the boss and say "Am I missing something? Was there something on this list that I can do or should do to move these projects along?" Don't talk about the other guy, make sure that you have covered everything you could reasonably do.

Is this mind numbing?

Yes. This is something that a strong team can work out without the boss. In a thrumming, high performing team this isn't needed. But you have case where accountability isn't being taken. You can take accountability for the overall status - but you can't take accountability for key tasks that you can't do on your own.

Often CCing the boss will make this real enough that your coworker will start to care. After all, you're not ratting him out, you're making the boss aware of a project that was important enough to pay you to do it. It's really easy to overlook people if they aren't pointing out that the lack of collaboration is making it hard to get anything done. But seeing one's own name next to a lot of unfinished, clearly worded tasks is hard to ignore.

  • +1 for the suggested process, and Don't talk about the other guy, make sure that you have covered everything you could reasonably do – Peter M. - stands for Monica May 16 '14 at 0:11
0

First things first, you need to stand up for yourself and you need to stand up for your project. If I have a project blocker (like you have with the requirement for him to set up your test environment.), then I immediately let management know about it. They will make sure he finds the time to do what he is supposed to do, they will suggest someone else who has the time to do the work you need done, or they will assign you to a higher priority project during the delaly. That is their job and by not telling them you have a problem, you are creating a worse problem, one that could cost you your job. Never let a project delay sit for more than 24 hours without informing management.

Don't let the fact that you think this person is nice stop you from escalating when he does not do the things you need him to do. You are not going to ever get him to work with you without escalating as he has decided your needs are not important to him. You are risking your own career by being too nice. In a year when you have not accomplished anything, one day you boss is going to come in a fire you. You have to make sure that others above you know what is blocking you from finishing a project.

-1

I'll say this, from a personal experience being the newbie. If the senior dev (ie., your mentor) had time to walk you through it, he/she would have done the whole thing already!

There's always a first time, and you need to figure it out. Part of the job of being a developer is to be able to read the code and understand it, and the other part is to RTFM/D and figure out what is asked of your project.

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.