How to mention that teammate accomplished nothing in team lead's absence [duplicate]

Question

My team lead went on vacation for 2 weeks, mid-sprint. So my team, 3-ish developers, had a fair amount of work to finish the sprint off. Then we were told to work on the backlog and bugs in his absence and to start a new sprint when he returns.

Another developer and I have only been here for a month, but have been recognized already for getting stuff done and working without needing micro-managing. However, while the team lead was on a vacation, one developer, "Joe", did nothing useful and actually slowed us down.

He would make tasks out of thin air that weren't requirements (unknown to us at the time), ask us for help after he spent way too long on them and then eventually just not complete it.

I normally would try to speak with "Joe" directly, but this guy is really difficult to communicate with and I get a feeling he might cause a scene if I said anything.

My goal, as a part of a team, is for the team to do well, and we would honestly be quicker if he did nothing at all.

How do I inform my team lead of this?

I'm sure he will see some of this in the source control paper trail on his own, but not all will be noticeable.

EDIT:

• We do have daily stand-ups which consist of "what have you done" and "what are you now doing"
• The other developer and I were not aware he was asking for help on non-requirements because "Joe" would just ask for help on a particular coding issue (e.g. how do I create this object?) and not questions specific to the requirement themselves.

Answer 1

You don't.

Carry on with your own work and let your Team Lead sort things out for himself when he returns.

It should be fairly apparent that this guy hasn't pulled his weight, so just let the natural process take place here.

Answer 2

If you do anything, then you will be labeled as the office rat, at best.

At worst, you will have people watching your every move, reporting every time you are five minutes late, leave early, have a long lunch, take an unscheduled break, or need to arrange anything for personal reasons.

It is the responsibility of the team lead, not you, to police the actions (or inactions) of the group.

If your goal is truly an effective team, ratting out a team member is not the way to do it as you will only cause conflict, not unity.

TLDR

How to you approach the team lead? YOU DON'T

Focus on your own job and leave the rest to the team lead. The other person will hang themselves or not. Stay out of this

Answer 3

Based on your description of the situation, there are two distinct issues:

1. Your co-worker seems to be working on tasks that are not related to the backlog and/or defect list.

2. Your co-worker is slowing you down i.e. impacting your ability to meet your own commitments.

Regarding #1: as other answers have stated, this isn't your responsibility.

I also wouldn't necessarily assume that the work isn't assigned. Someone may have approached "Joe" and asked them to take on a a side/research project. (In an agile environment -- you mentioned sprints -- any work should documented in the backlog and/or on the board, but no person or organization is perfect.)

"Joe" may also be a relative or friend of someone in upper management; that sort of thing is in my experience all too common. Yet another reason to let your team lead take care of the issue.

Regarding #2: if it's impacting your productivity, that is something you can and should try to address.

I would suggest you start one-on-one and set some boundaries: if you're "helping" "Joe" for more than, say, 15 minutes at a time, say, "Hey, I'd love to work with you some more on this, but I'm working on X and Y and we really need those done by the end of this sprint."

If that results in a scene -- or you have reason to believe that it will -- then maybe it is time to involve the team lead. But, in doing so, focus on the impact to your productivity. Ask for guidance in handling the situation: you want to do what's best for the team, but you need some direction as to what that is. (This is a question of prioritizing the use of your time; don't assume you know what your team lead and management want ... for example, you might be asked to spend some time pairing with Joe.)

Answer 4

I've actually had this problem, and sometimes still have this problem on my current team with people I've been working with for over a year.

Personally, I am a big fan of accountability, and that's why I struggle with the say nothing approach. Before I go on, keep in mind that accountability doesn't always mean telling someone their work is useless or that they haven't done anything meaningful for the team. It doesn't have to be degrading or a personal attack (Something I had to learn over time). Sometimes it could be a simple misunderstanding of priorities, unclear expectations of what to work on, weakness in areas where the work truly was, or maybe Joe has personal things going on in his life.

So how does accountability come into play? At the end of the day, we are all working on something to reach a goal. In software, it's typically to solve bugs, built out functionality in a system, or harden an existing product. These are basically the job requirements at a very low level for a programmer working on a code base at a company. In my opinion, if someone isn't doing their tasks, not only is it a liability for you and the team, it's a waste of the company's resources (time + money).

Something that will affect the scope of what makes sense for you based on your question involved: Who, in the Team Lead's absence (or otherwise), delegates and prioritizes work? This is the person who should be held accountable in the same light as Joe.

...did nothing useful and actually slowed us down.

This is a very big statement and will most likely be perceived as a personal attack. What will help is re-constructing your criticism to be more geared towards

1. Understanding how Joe started working on the Tasks that he deemed important
2. What Tasks The Team feels were more important and valuable that he should have been working on
3. You are concerned that the work he was doing wasn't contributing towards the goal of the Sprint

You need to show that your concerns are valid and that they are about the work [not] getting done and they are not actually with the individual. (If you truly do not like Joe, find another team, or ultimately another job. It's not worth the negativity it brings to be around someone you dislike)

He would make tasks out of thin air that weren't requirements (unknown to us at the time), ask us for help after he spent way too long on them and then eventually just not complete it.

This feels like "bad house-keeping" since there was work going on that wasn't being tracked, no one was asking why this work was being done, and it seems like people were focused on other things and lost sight of, again, the goal of the sprint. When Joe asked for help - that gave you a very small window of opportunity to dig a little deeper and determine why he was working on these tasks and what they had to do with your plate of work. In the Sprint, the team should usually have a good idea of what's left to do and the higher priority items on the backlog (that I'm assuming everyone has visibility into). Work in progress that does not get completed is not always a bad thing, depending on the work. For example, if Joe was researching a new technology that would help speed up database connections, for example, then I would say that's potentially valuable, although the priority of other work could come first. Open communication resolves issues like this.

Ultimately, a Team Lead has much more on their plate (usually) than the developers that work under them. The Team Lead will not go through all code reviews and check-ins. I believe this is the case because there is mutual understanding and respect that your peers will do their work as prescribed and if any issues arise (we couldn't do X because of a dependency on Y), they will be brought to light during a meeting. It doesn't do a Team Lead any good to micro-manage 2-weeks worth of work by reviewing every check-in. That's where you need to focus your energy if you're going to speak up about this, and refrain yourself from personally attacking Joe - it will do more harm than good.

Again, the things to focus on here are: Making sure your Team Lead knows that this is a genuine concern of yours and you aren't simply complaining. What should everyone be working on? Who delegates that work when the Team Lead is MIA? Have open communication about the work being done and how it contributes to the goal of the Sprint / Team / Product. If you don't feel like something being worked on is valuable because there are higher priority items - there's nothing wrong with that, but you have to build your case on facts.

Answer 5

I would add that the facts should speak for themselves.

I don't think you should "rat out" "Joe" - but given there should be some sort of "stand-up" where everyone report past and present status.

When You report that you worked on Task 1, 2, 3 and fixed bug X, Y, Z all regarding tickets 8, 9, 10... and you closed 2 of the three tickets. The third ticket? It's in Joe's hands waiting on his response.

Then you watch as Joe says he worked on This, That and The Other and... well... those things aren't associated with tickets except in passing... and no tickets were closed in response to the work done...

The comparison should speak for itself.

If you emphasize what you did... the silence with regards to what Joe did should be easily heard if your Team Lead is paying attention.

Answer 6

I think what you should do is to present a report of activity with all the tasks you accomplished every day - you can explain this with a simple reason, you are new there.

You can clarify if the team lead wants you to manage strictly the activities from the sprint or he encourages to resolve other tasks like what Joe did.

This should be enough to warn him about Joe and make sure he knows your accomplished tasks without saying something specific.

Answer 7

While I like the "you don't" answers; I think there's a potential solution in here for the future. While I generally agree that its your Lead's job to identify who did what (in part so they can consult the right person about mistakes and similar) this can be done in a variety of ways for review steps.

If you currently lack a code-review step, a "weekly review" or "progress report" that you send to your lead, stand-ups where you report out what you've done, or a variety of other tracking-meters; these can be helpful in getting un-motivated persons noticed or motivated.

Similarly, it sounds as though you don't have a task-tracking system either (such as Jira.) If you do, then his lack of progress is already being tracked implicitly because at some point your lead should notice that tickets under his name don't seem to move, or that tickets are rapidly spawning and then being invalidated. In our communcations server (hipchat) we have a Jira channel for our team that blurts out all the information that goes through it, such as new tickets, change in status, etc.

---

Additionally, as someone who does skunkworks-y things, you may not see the value in his work but he's quite potentially been hired to do weird things like this. Some people are hired, not to work 40 hours or be great at the basic part of their job, but for their auxiliary contributions (or perceived ability to do them.)

In my case, a tool I built (and probably wouldn't have authorization to build) has completely changed our approach to a primary job on our team and helped discover such rampant issues in other teams that the three teams together have been refactoring our entire approach. Additionally, we have more accurate products coming out of our teams, better requirements, better diagnosis of issues, and find the issues much earlier. Our tasks have gone from weeks to hours.

Such a contribution may be once in a blue moon; but may be the exact reason they hired this guy; hoping that they have a brain that will approach the search space of the problem in such a way as to come up with a great solution.

---

Finally, I've also worked with the type you talk about. She basically didn't get anything done, didn't use the workflow system appropriately, refused certain categories of tasks (because of unfamiliarity with that section of the code; the Self-fulfilling tragedy of it all!) and other issues.

That said, she didn't get canned directly; only (maybe) let go as a result of moving away. My best guess is that it's difficult to fire someone in my job or that the lead doesn't have the stomach for it.

Answer 8

I think that every person in a given team has the responsibility to speak up if they see something that is detrimental to the team's progress. To completely ignore it makes you somewhat complicit in the failings.

You could say that one person didn't do anything while your team lead was away, which caused the team to not meet the sprint goal, or you could also say that your team as a whole didn't work well enough together to meet the sprint goal. Two different perspectives of the same thing.

Since you are running sprints and stand-ups I will assume you are also doing sprint retrospectives. In the sprint retrospective you can bring up the fact that you don't think that the team did well at prioritising tasks and that stand-ups were not effective (which is true or the whole team would have known that people were working on the wrong things).

You could elaborate by saying that people were sometimes not working on the most important or most relevant tasks. You don't need to name names.

It might be worth also discussing why your stand-ups didn't alert anyone to the fact that people were working on things they shouldn't have been. Maybe you need a change of stand-up format.

Then I would hope that your team lead would instigate a discussion regarding this where as a team you can discuss possible causes of this and possible actions for this.
For example, a possible cause may be that the person started working on an issue and then discovered other semi-related issues and started working on them first as part of the original issue, instead of stopping and creating a new issue, discussing the potential change in scope and/or effort and then continuing.

If you're really nervous about the other person perceiving it as an attack you could phrase it in a way where you include yourself, for example by adding that it is something you know you do yourself from time to time or it is something that everyone struggles with sometimes.

The purpose is not to point fingers and play the blame game, but to use constructive feedback to identify weaknesses or issues within the team and to work together to resolve them.
Your main aim is to get the team working together as best as possible.

It will often be the case that the person is aware of this problem and wants to fix it, but doesn't know the root cause, or can't work out a solution. Or they might be blissfully unaware of the problem at all.
In both those cases, having the discussion as a team will help them to solve it and everyone will be happier.

There will obviously be cases where you will have a team member that just won't be a team player and won't follow the rules of the team, even after trying to work it out in a friendly fashion. In that case, then you could talk to your team lead and say that you are concerned that the issue of the person working on the wrong thing is not getting resolved, even though it has been discussed in retros and stand-ups.

Then whatever happens after that is above your pay grade, unless the team lead asks for further assistance from you in the matter and you agree to help.

Answer 9

I do agree with most of the answers posted so far, it is not your Job to up the Performance of the Team.

However if you want to make your circumstances known to your Team lead you could use the daily standup after to fill him in of what happend in his Absence. Now you should definitly avoid talking bad about Joe, instead just talk about everything YOU have done the 2 weeks, also include that you were helping Joe (not in a negative sense, just to explain how you spent your time). No one will bat an eye since you just want to fill your teamlead in. You may also want to convince your other coworker to do the same. This leaves Joe with 2 Option in the daily:

1. Lie outright about what he has done: This should be noticeable by to your teamlead either in the daily already or when he checks out the commit history.

2. Say what he was doing in that Time: If your teamlead is somewhat up to his Task he will realize that this Tasks where not in Scope for that Sprint.

In both cases your teamlead should notice something wasn't going as planned. At this Point it is his Job to determine how to continue. Also you save face if there was any instruction from your Teamlead to Joe to take care of those Tasks, that you might not been Aware of.

Answer 10

Focus on outcomes, avoid negativity

When your teamlead comes back, a question of 'how did it go' is more than likely.

Rather than assuming/implying that something bad has happened, stick with the facts. In your case something like this seems appropriate:

In general my work on sprint tasks went well, but I was asked to help a bit more than usual on out-of-sprint tasks

If your team lead does not mind, then you should not mind too much. Probably he will at least be curious, then you can simply indicate that you helped Joe with some stuff (without negativity in your expression!). It is then up to your teamlead to investigate what that stuff is, and evaluate whether he is happy with it being prioritized.

---

As you can see I try to look at things positively as much as possible. However, if Joe was obviously doing something useless to the company (like setting up a streaming solution so he could watch his cat) then this answer is not suitable for the situation.

Answer 11

You should do what is ethical, regardless of its impact on your career and team standing.

This is very similar to the situation I find myself in presently. Essentially, someone is not doing their job and it costs the team, and it also costs their individual coworkers traveling on the same ship for which they need to work harder to make up or suck up the loss. It is absolutely something that is actually unethical to remain silent about.

The way I escalated the situation -- after more than a year of more friendly remediation attempts lower in the corporate hierarchy, which didn't work -- was that I put together a list of that person's wrongdoings and explained how each one affects the whole team badly -- in our case also the client that pays us. I explained how I had to do more work to make up for that person but that is not a realistic and sustainable workaround.

Why the "ratting" is not the despicable babyeating gesture the "workplace experts" here are making it to be: Because you could be working at a hospital or the fire department and your coworkers' incompetence may cost some people their lives. So make no mistake -- "ratting" is the right thing to do regardless of its impact on your career and team standing (and I'm putting an exclamation mark here) ! And even worse than ratting demonization is the idea (widespread in this forum) that you shouldn't do it to preserve your social standing among your coworkers because it is good for your career overall (who cares about morality?)

In my case, I was heard out by the upper management -- which was also criticized for not paying attention and not being hands on to see the problem earlier -- and the preponderance of the evidence was so overwhelming they had to agree with me. I suggested that the person in question was so hopelessly incompetent that they deserved to be let go (replaced by someone who can do the job competently and reliably) and that any further benefit of the doubt was akin to sticking one's hand in the fire for the umpteenth time and that it was easy for the management to do it because the client was basically clueless and can't monitor individual contributors' performance, therefore the guy gets blended with the rest of us. I believe you can put together a similar case but it is important that you document it in a structured, dispassionate presentation that is focused on the impact on the team and not sound like a personal feud. It is also critical that you yourself be credible to issue such warnings by being reputed as competent.

Now, you should note that, like I said, this is likely to take a hit on your personal team standing and career within that company than not. But life presents us with challenges of this nature where the ethically correct thing to do is to bear the cost. Since you seem like a competent and confident individual (have been recognized already for getting stuff done and working without needing micro-managing), I am sure you can find alternatives in case this morally admirable course of action starts having intolerable political consequences.