I am someone who is an excellent individual or hand picked team performer, but generally a bad team player. How can I be less irritating?

Question

This similar recent question popped up, but I am more interested in mitigating frustrations (without compromising my productivity) rather than getting away with them.

I am someone who is immensely productive as an individual contributor or with people I select myself, but someone who is generally disruptive to any team I join in a way that pleases management but leads to resentment from other co-workers.

Like the other question, I work a lot of unrecorded overtime. Most work the standard 40 hour workweek. I am probably closer to 55 in office and I am frequently remoting in on the weekends or at 2AM if I am bored. I also consistently eat at my desk while others go out to restaurants. As one of the comments mentions in the other question, I am skewing the metrics used to measure programmers and that is one of the issues.

The unrecorded overtime has the benefit of letting me pull 3-5 items off the backlog every two week sprint in addition to my assigned tasks. I consult with the business analyst (one of the few team members I get along with at work and someone I am not compared to by management) and he generally lets me pick up anything I want that has a complete user story. This got me a 15K raise three months in.

Business Analyst and Project Owner are pleased with that because a project two months behind when I started is on pace now because of the extra work. My manager was also under the gun for the delay, so my actions have lifted this particular rock off his back. The area of friction with colleagues is that management is now breathing down their necks for seemingly having dramatically lower productivity. They are also getting scrutiny for taking vacation (something I just always have paid out) or sick leave. Basically, management is starting to view them as slackers. That is not really a fair assessment of them.

Another area of friction is that the Project Owner can email me requests for new features and have the answer always be yes. I am a people pleaser and am fine with doing more work, so you want X done for tomorrow? Sure. Problem is, she isn't limiting requests to just me and everyone else has to tell her no. She called one developer "uncooperative" in a sprint planning session for doing that.

I have had this issue at other jobs as well. Once, when it was my week on support, a client mentioned that he wished our software could do X on a phone call. I wrote it overnight, sent it right to QA the next morning, and had it in prod in a few days. A few months later, the client had a similar request for another developer and ended up complaining about him when he refused.

I am not really worried about a lack of help from co-workers (I feel like a dependent going to the emergency room for an allergic reaction, so I am not the kind of person to ask for help from anyone for anything).

Same with the interpersonal relationships, as I am a boring person anyway. Other than career achievements like graduation, I have little in common with most people. I am not someone you would want to have a beer with or be god father to your children.

I have tried concealing my level of work and just lying about what I am working on during standup and not taking on that many items during sprint planning, but the Business Analyst publicly praises me over it, it comes out in sprint review, and I can't spend my day hopping around the office trying to avoid people to make it seem like I work less as our office is small. I can spread my work around different developers for code review and different QA people for testing, but they eventually update Scrumwise (where I try to conceal tasks at the bottom where few scroll).

This brings up another issue, QA resources. Frankly, I think the other developers are also at substantial fault here, most of them start by working on the largest task they are assigned. That means they have nothing to give QA for a week (and before I arrived, QA had a 2-3 day break after clearing the unfinished QA stuff from last sprint). I do the medium and small tasks first so that they are all done, QAed, fixed, QAed again, and into UAT before the end of the first week, i.e. before anyone else has passed stuff to QA. I do my big task which takes the weekend + a day or do and it is into QA as their stuff finishes its first round. But then I return to smaller stuff off the backlog and am filling up the QA queue as they want to test their smaller items. Our definition of done is such that it must pass QA, so it further screws with their metrics.

I am basically doing this because I am a people pleaser and find people being anything less than thrilled with me uncomfortable.

How can everyone be made happy? Is there a way to make sure only management knows what I am doing without letting other developers know? I basically want to cloak what I am doing from those who might find it frustrating.

Answer 1

Stop hiding your overtime.

The root cause of the problem here is that you're working about 1.5 times as much as your coworkers, and accomplishing an increased number of tasks as a result, while appearing to only be working as much as they are. If you let everyone know that you're working that much overtime, that should be mitigated; if you're working 1.5 times as many hours, it's only reasonable to expect you to accomplish 1.5 times as much.

Just talk to your manager about the best way to make sure that everyone knows that the reason why you're accomplishing so much more than the other programmers is because you're working so much overtime.

Alternately, go work for the video game industry.

Heavy "crunch" overtime is a very common workplace factor of video game development; this is partly because there's so many would-be game developers that the companies can afford to treat their employees poorly since they can be easily replaced, and partly because they have a culture of using "passion" as an excuse for employee exploitation. As a result, working the way you do would be regarded as normal in that industry.

Answer 2

How can I be less irritating?

There is no real reason to change. One suggestion though, with this sort of commitment (enjoyment) with work, you may want to think about making your own product in your spare time instead of working for others in that time.

This has the benefit of bringing your workload closer to your colleagues output, and setting yourself up for the future. This worked out well for me over the long run but of course individuals vary.

Answer 3

You want to please people, but from your description you appear to be actively displeasing your teammates. So work on that.

You already seem to be using a partially agile approach where you have a product owner and development team agreeing stories to be done during a sprint. What's missing here is that the product owner seems to be asking individual team members to do things, rather than asking the team. The standard way of dealing with what's the product owner selects from the backlog in XP is to have the entire team take responsibility for the entire contents of the iteration or sprint and then have the team members themselves divide up responsibility for individidual items. This can change over the course of the iteration; if something Alice said she wanted to do looks like it's not going to get done, have a quick team meeting and let Alice suggest how the stories might be shifted around so that someone else can help with whatever's looking like it's in trouble. Don't bother the product owner with the details of this; just come back at the end of the iteration with the team having done the work and have the team take the praise for that.

As part of the process, make it clear, especially through your actions, that you will never refuse a request from another developer for help with something. (Ideally the entire team should be doing this, but this is best sold through demonstration by someone with the time and energy to be able to do this, rather than telling others what they should do.)

When you find yourself with spare time, if you can't convince other members of the team to let you help them with their stories, look around for other internal technical improvements you could work on that are not business stories but benefit both the team and the business, such as improving the test framework or fixing up that nasty chunk of code that is constantly causing annoyance as you the team works on things that touch it. Look especially for things that are annoying or slowing down other team members that they feel they don't have the time, energy or willingness to work on themselves.

If you can pull this off you'll probably get less immediate personal recognition from management, but you'll get a lot of recognition from your team that you're an incredibly valuable asset, and that will filter up to management as well. And there will be plenty of good work to be done that you'll enjoy without making your team members look like they're slacking.