How much can I get away with making management happy but irritating co-workers?

Question

I'm a software developer on a Scrum team and my actions make me a favorite of upper management but seemingly frustrate my co-workers. Now, I don't really care if they are unhappy, but rather I am looking for a strategic risk assessment.

Here is why I am having issues with my co-workers:

1. I am not really a team first kind of player. This has yet to cause explicit problems, but I am not one to consult, not one to wait for consensus, etc. If I have an idea, I just throw it right up to decision making level. For example, we had a client who we told that we couldn't deliver a major component for several months. Well, 90% of that estimate was based on a relatively minor feature which did not matter too much for that particular client. I emailed the product owner to say that I could finish the remaining work and have something releasable by the end of the sprint as long as they agreed that the feature would be incomplete. The sprint was then shifted by the product owner based on that email. Several other developers found that jarring. My team members also didn't want to document the list of product features because "Agile doesn't have documentation." I got shot down when I proposed that during one of our weekly issues meetings. I then pitched it to the product owner (also our sales lead) and it was requested officially by her, so we had to produce a 5 page list of what features existed.

2. In 8 months, I have never missed a sprint goal. I work on a project considered to be critical for the future of my company as it is the flagship software we sell. In those 8 months, I am the only person to never miss a sprint goal. When I say that something will get done, I get it done, even if it means working a few extra hours (up to 10 a week). Sometimes I will take additional tasks off the backlog and do them as well. Others don't work those extra hours, so they often have to report that their tasks are not complete. The project owner very publicly complains about the other developers when this happens. It doesn't help that the project owner will often hand their task to me and I get credit for finishing it.

3. I am a relatively junior developer who gets to work on the greenfield. A large bone of contention between myself and the other developers is that I am the only full time employee who gets to work on the project 100% of the time. Everyone else alternates between support and greenfield work. I do not do support because I am one of the few with React knowledge. There is minimal React work to be done in support and it is maybe 70% of the greenfield. The other developers complain a lot about this.

4. I did something very visible that made every member of senior management know my name. It's hard for me to say exactly what I did without it being revealing, but I am learning to toot my own horn and do the tasks which people notice. In particular, I did something that which meant that a company wide email (~800 in the company) was sent out praising me. I am the newest developer at the company, so many are feeling underappreciated.

I don't have a need to be well liked. I don't need infantry level allies. I am just wondering what risks might exist for me going forward.

It was suggested I add this comment to the question:

I am not necessarily competitive, but rather just extremely sensitive to incentives. Our individual Velocity score seems to be how we are judged. A team member who spent their sprint unblocking people but not completing their own work would hear about it from the project owner.

Answer 1

There are a few glaring issues in the OP post that seem to be missing from existing answers.

When I say that something will get done, I get it done, even if it means working a few extra hours (up to 10 a week)

Does management know that you are doing all this unpaid overtime? That's almost a week worth of overtime every month, and I imagine unpaid and untracked as you are working in sprints. And that's a problem because not only you are devaluing your time (you are effectively cutting your hourly rate by 25%) but also you are screwing up the curve for other employees, ones who do not wish to take a pay hit just to keep up.

If that's also what you need to do in order to deliver sprints, and you have to do it every week, then that's your own doom now - as you've built up expectations in management that you are delivering 50 hours worth of work, instead of the usual 40 (or whatever is the core hours amount at your place) and you will have to continue doing so or come clean about your endless overtime.

I am a relatively junior developer who gets to work on the greenfield.

I can't imagine that this alone would be an issue, but if you have a flippant attitude about it, throwing the fact that you do not need to do support work in their face... Yep, that will make people very unhappy very fast. A much better response to that is to try to help them, somehow, even if it's to make a coffee run when they are in the middle of heavy support work; small gestures go a long way. That is if you really cannot help with the support work, and are not simply using React as an excuse to not do it.

I don't have a need to be well-liked. I don't need infantry level allies. I am just wondering what risks might exist for me going forward.

Being liked in the workplace is usually optional and sometimes not even desirable. But if your co-workers do not respect you, then they will not help you in time of needs, nor will you be ever put in a position of leadership, or even principalship. Even senior development will be a struggle if you are alienating the people you are working with because as a senior you are expected to guide and support junior and mid-level developers.

You may think that it's because they are developers, and with management, you are getting perfectly alright, but the reality is that this is the case due to limited exposure. The developers see and communicate with you multiple times a day; management doesn't. I can assure you that if you move up and work very closely with them, this will be a problem too, and for the very same reasons, you are facing now.

Even if you are in the current work just to quickly make a name for yourself and get a great reference, the behavior you are showing in the post will be picked on by any interviewer worth half their salt and will be weighted against you. So make sure that you are really that technically excellent that your no-team attitude will not outweigh it when job hunting.

And I put a bit of doubt in your technical excellence because, so far, to meet the sprint goals you have to do overtime quite regularly. And that's not a sign that you manage your work greatly, or overdeliver or are supper efficient, but a very bright yellow flag that something is wrong. And that's despite being 100% focused on the project work, without having support work or helping out/mentoring teammates to worry about.

Something to think about.

Answer 2

Friction with co-workers is often a "straw that broke the camel's back" situation where each individual friction point is not that big of a deal, but the amount of friction points does become a bigger deal.

Your individual points can all be argued to not be reason enough to socially exclude you, but combining them does create the image of a coworker who is less than pleasant to work with, which is statistically going to lead to social exclusions. I'll provide feedback and an alternate interpretation to your raised points, taking the liberty of differing points of view and interpretations.

I'm sorry if the below reinterpretation of words comes across as blunt at times, but I think you need to see the other side of the coin, because you're currently working with a go-getter attitude with little disregard (or genuine obliviousness) to the effects of your actions.

---

1

I am not really a team first kind of player.

This is a red flag statement. It's perfectly fine to be a good solo dev, but it's less desirable to openly present yourself like that. It suggest that you immediately dismiss your team members in favor of yourself, which doesn't help to build trust and cooperation.

I am not one to consult

This again is a matter of phrasing. If you don't need advice or guidance and aren't struggling with your tasks, that's perfectly fine.
However, your stance on others consulting with you is unclear. If you are similarly averted to it, that becomes a strong friction point.

not one to wait for consensus, etc. If I have an idea, I just throw it right up to decision making level.

If you bypass the team, you effectively dismiss your coworkers' possible contributions. What you're doing isn't against the rules but it does bypass some social checks that will hinder your interpersonal relationships.

Think of it this way: when I communicate with my landlord (e.g. about a broken pipe), I am allowed to let this be done through legal channels right from the get go. I'm not doing anything wrong. However, I would be massively changing the tone of communication with the landlord compared to if I talked to them first to see if they were already willing to fix the broken pipe.

Me going to a lawyer without first talking to the landlord is like you talking to management without consulting the team. It completely omits casual conversation and dramatically impacts the tone of the work environment, which puts people on edge and is not going to foster a great interpersonal relationship.

2

In those 8 months, I am the only person to never miss a sprint goal.

There is an underlying tone of arrogance in your description of your role and your achievements. This statement is a more concrete manifestation.

Why are you even tracking this? Why would it matter? Should others feels bad for having missed a sprint goal? Either you're saying it doesn't matter, and then this statement is irrelevant, or it does matter, and then you've got a really competitive view on how to interact with your coworkers, which is at the heart of them not liking you.

On top of that, you list yourself as a junior developer. Most commonly, you will be getting simpler tasks than medior/senior developers, which can massively skew the odds of you hitting your sprint goals.

To showcase my point: If you put me, Michael Schumacher, Lewis Hamilton and Sebastian Vettel (world class Formula 1 drivers - in case you don't know them) in a room, I am the only one in the room with a 100% winrate on racing. Providing context, I only partook in one race when I was 14, but I did win, so I clearly rank better than Michael and Sebastian, right?

Even if we ignore the statistical juggling that this statement entails, this is again one of those clear "I am better than my coworkers" statements that does nothing but harm your interpersonal relationships with them.

When I say that something will get done, I get it done, even if it means working a few extra hours (up to 10 a week). Others don't work those extra hours, so they often have to report that their tasks are not complete. The project owner very publicly complains about the other developers when this happens.

I can definitely see where the friction is coming from. You are driving up the standard of an employee's workload. Rather than just advancing yourself, it is actively casting your coworkers in a bad light.

I don't know your personal life or that of your coworkers, but taking a statistically accurate stab in the dark: junior developers are young and more often don't yet have a family/children of their own, which makes them much more flexible to perform overtime compared to someone older with more life commitments such as a family and/or children.

Don't get me wrong, I'm not saying that you and your coworkers should conspire to keep the workload artificially low. That would be wrong too.

But trying to race ahead and then having it publically blow back on the others will of course do you no favors in your interactions with them. This isn't your fault - your manager is the one generating the negative feedback towards the others who don't do the overtime, but the social blowback from your coworkers is naturally directed at you instead of the manager.

4

In particular, I did something that which meant that a company wide email (~800 in the company) was sent out praising me.

By itself, this is not an issue. Deserved praise is deserved, regardless of position.

I am learning to toot my own horn

However, this is an issue. Based on your question, it is clear that you are focused on personal achievement which you express by comparing yourself to the team, which you bypass on every occasion where it benefits you personally. On top of that, you tamper with the workload curve by taking on (presumably unpaid) overtime to achieve your sprint goals, which not everyone has the freedom to do; and are clearly aware that this is generating negative feedback on others from management.

You're currently working with a go-getter attitude with little disregard (or genuine obliviousness) to the effects of your actions.
If that's how you want to approach your career, that's okay. Some people have made great strides using this sort of "dog eat dog" approach to their career. But it's not going to be making you any friends.

You can't both distance yourself from people and then wonder why people are distant from you. It's one or the other.

I am not necessarily competitive, but rather just extremely sensitive to incentives.

What exactly do you think competitiveness is, if not a behavioral response to the incentive of winning?

I don't have a need to be well liked. I don't need infantry level allies. I am just wondering what risks might exist for me going forward.

What happens when you don't have the free time/energy to take on overtime anymore, and a new junior dev is able to do so? Will you be happy now being one of the "lazy" devs who should take the example of the junior?

What happens when you run into a conflict with your employer, possibly over something completely unrelated? Will anyone have your back or vouch for you, after you've hung them out to dry?

What happens when you happen to be assigned tasks that, through no fault of your own, end up not meeting their sprint goal? Will you still argue your "results over effort" opinion when your result isn't perfect either?

None of this is a guarantee. You might always have the time/energy to keep this up, you might never get a task you can't complete, and you might always have a great relationship with management. But the odds are low.

Our individual Velocity score seems to be how we are judged. A team member who spent their sprint unblocking people but not completing their own work would hear about it from the project owner.

The saving grace here is that your work attitude seems to be a product of the environment you find yourself in. Management seems deadset on pitting employees against each other in a misguided "competition breeds results" attitude.

I hope you can see the blatant issue in negatively reviewing someone who spends their time helping their coworkers. Clearly, management's metrics are not accurate measures of contribution.

If you want to play the game and reap the rewards, I can't tell you you shouldn't. However, if you decide to go over dead bodies, which is what you're currently doing, then you're going to reap the consequences from eroding your team's trust and cooperative spirit.

Answer 3

Some companies use 360 Reviews. This is where your end-of-year review (and any salary increase or bonus) is based largely on how your peers and underlings view you. Not just your management.

If they introduce that at your company then you might have shot yourself in the foot.

---

Additionally, you might find that it is very difficult to achieve a pay rise via your friends in management. Management are incentivised to pay you as little as possible.

A much easier way of achieving a significant pay rise is by moving to a different company.
The easiest way to do this is by having connections at that other companies.

I.E. a longterm strategy is to have all your peers love working with you, so when they get amazing jobs elsewhere they are on the phone offering you to walk into a great job.

It sounds like your colleagues might prefer to blacklist you than phone you, so you might find that once they have all moved on to bigger better things, you are the one left behind working overtime.

Answer 4

Okay, let me say this first: You are not a team player and your so-called Scrum team is not actually a team either. If it were, your behavior would not be possible, because there would be no individual goals or performance metrics. So this is dysfunctional on both ends, it's not only you.

I don't have a need to be well liked. I don't need infantry level allies.

Well, at some point you will find out that it is extremely lonely if you don't make friends with peers. Work is a huge part of your life, even if only counting hours. Going through that with no friends and only people who dislike you can be very lonely. I know it's "just work", but it's way better if you can share a funny story with people at lunch instead of gulping down a burger at your desk alone.

I am just wondering what risks might exist for me going forward.

Well, the most obvious risk is that if you are so good you are "irreplaceable", you cannot be promoted. You are needed right where you are. You can only be promoted if there is an acceptable replacement for you.

The other strategic risk (and this might sound weird) is that with this cutthroat attitude, you will be promoted. How is that a risk? Well, it means you will go into management. But management is not "programming just with more power to decide". Management is a completely different job. You basically uninstall your IDE, forget about syntax and compilers, frameworks and functionality. Your job will be emails and meetings the whole day long. Be very careful when you make this decision: do you want that? Is that what you want your day job to be, never touch a compiler or write a line of code again? Because that is where you are headed. Some want that. Many don't. Make sure it's where you want to be, before you go there.

Answer 5

Budget some of your time and effort to helping your teammates improve themselves.

Select your opportunities carefully to maximize the return on your contributions. Don't get bogged down finishing other people's work for them, but stay with advising and teaching. Work on those who will be seen to benefit the most from your help. Don't fake it -- really help out -- but make sure all your teammates see you doing it.

Eventually you are going to want to form a team and lead it, and then a department, and maybe a division. Your success will depend in large part on the staff you choose, and you will want to attract the best people in your company. It will not be enough to be recognized as one who does not denigrate or blame others; to pick from column A you need to be known as generous and helpful.

Answer 6

Nobody so far seems to have answered your question about a risk assessment. I'm not a developer professionally (hobby stuff, and some Linux contributions), but I do risk assessment professionally.

So what are your risks here. The main issues I see:

1. Continuity - can you keep this good track record up consistently into the future? Management is well-known to not remember your past accomplishments for long. Goodwill with management goes away quickly if you don't keep delivering.
2. Sabotage - if you continue to annoy your co-workers, it is possible that they begin to sabotage you. As a junior developer, you can easily be sabotaged by a senior. It's easy to find a task that seems easy on the surface but is actually a damn hard problem. Push you to make a delivery estimate before you've had a chance to properly analyze the task, and there you are, between your own estimate and a problem too hard to solve in that time.
3. Teamwork - while a lot of development work is done independently, not all of it always is. There are points where teamwork is necessary and/or beneficial and having at least a working relationship to the co-workers will be helpful.
4. Middle Management - where in all of this is your immediate supervisor? Do you list him among the management you are making happy or the co-workers you are annoying? Because these guys (your boss and his boss) can make your life hell, or just completely block your career. I've seen enough office politics in my life to be completely tired of it. You will just not get that promotion, or raise, or even those days off - for more or less clearly fabricated reasons. I've seen a necessary team leader position stay empty for a year despite two very qualified internal applications. Then a friend of the boss got the job and it became clear it had been intentionally kept empty for him and was only officially open because HR had demanded they take applications to fill it. Those kinds of things.

The biggest short-term risk is sabotage. There are countless ways how co-workers could make your life difficult and/or spoil your reputation with management and from what you write some of them are probably close enough to thinking about such options already.

The second risk is continuity. You already work overtime. Do you need that or could you deliver maybe not star-level but adequate, slightly-better-than-average level work in the allocated work hours? Otherwise, one private emergency that takes your time endangers your position. As soon as you're not the star developer anymore, those team issues rise to the top, and I've seen people not hired or being fired not because they were bad at their job, but because they didn't fit into the team.

To mange those risks you should a) tune down the annoying part. Don't change what you are doing, but don't gloat about it, don't put it in the face of those worse than you, and where it's essentially for free, include them. Something as simple as writing "we" in a mail to management instead of "I" can make a huge difference when the thing comes full circle back to the team. Management will probably understand that it was you, but the team will see themselves included in getting the credits. It's also a good excercise if you want to rise to a teamleader - never take credit for what your team did, always say "we". And b) you need to bring down your working hours and manage your time to ensure that you can deliver the quality people are used to without overtime. Either you work more efficiently, or you slowly lower expectations. But you need to bring these things in line because otherwise either burnout or a private emergency that eliminates your overtime will do you in - not immediately, but sooner or later.

I wouldn't worry much about 3 (Teamwork), but keep it in mind and make sure you're not becoming too much of a lone wolf.

4 (Middle Management) depends much on the answer to where you put your boss. If he's on the list of people you regularily annoy, then that is an immediately important issue, because as soon as he thinks you are not untouchable anymore, he will make you pay. Most middle managers are shit and scum, the longer they've been at that level, the more (good people rise higher, those who've been middle management for a decade or more aren't good enough for anything better and they've begun to realized it).

Answer 7

First of all, your question title reads:

How much can I get away with making management happy but irritating co-workers?

However, you do not state a goal. Do you want a promotion, a salary increase, praise, learning opportunities? By not specifying any goal, you have made it impossible for us to tell you that your attitude is counter-productive.

However, even without a stated goal, there are problems in your approach:

Organizationally you are part of a team. You might not like it, you might not like the team, but I doubt anyone but you thinks you're outside, let alone above, your team. Obviously, your company didn't put you into a team for nothing. Your company expects you to act like a team member, not like a shoot-from-the-hip cowboy going it alone.

In 8 months, I have never missed a sprint goal [...]

extra hours (up to 10 a week).

See, sprint goals are defined for teams and teams should be able to maintain a constant pace indefinitely. However, you achieve "your" goals only by working overtime, up to at least 25%. Ergo you are not able to correctly estimate how long sprint items will take. That's three additional issues right there.

My team members also didn't want to document the list of product features

Your team members are kind of correct here. The product owner should know what features he has requested thus far. You should not have taken on this responsibility, at least not this easily.

I don't need infantry level allies

An infanterist absolutely does need infantry level allies.

An alternative approach that aligns with your view. Now, let's assume that you are indeed as good, productive and indispensible as you think. Then do quit your job. You don't need to be deployed to the trenches, chained to an employment contract, organizationally caught in a team full of underperformers. Hire back as independent contractor. You won't have team members, you'll probably have a shorter chain of command and a longer leash. Plus, more money!

Answer 8

How much can I get away with making management happy but irritating co-workers?

There is no limit so long as you watch your back and use the job as a stepping stone rather than a career.

You won't be there forever and making friends is not your goal. Just remember that you have made some people dislike you, so you need to be careful. Rise as fast and far as you can and then move on.

Eventually you're going to grate on management as well, so don't hang around too long.

Answer 9

How much can I get away with making management happy but irritating co-workers?

This is hugely dependent on the culture of your company. Some company love these so-called "rockstar" or "10x" developers because they seem to offer a very simple solution to a difficult problem: "just do it". They value their contributions, reward them and elevate them.

However, in some cases these "super" developers can be hiding issues from management (they might be working extra-long hours, or they might not be sharing knowledge with their team mates), leaving companies in a vulnerable position (what if the only person who knows the product leaves?). Of course, that could actually work to your advantage.

Other companies are aware of this and actively avoid that kind of behaviour. If somebody exhibited your behaviour in my company he or she would probably hear from management. As I said, different companies, different values.

You might think burning the midnight oil is a good thing and even necessary. Others can see it as a lack of resources. The question to ask yourself is: how long do you want to pull this off? At some point you might want to start a family or you might have to care for an elderly relative and might find that you can no longer pull all-nighters.

If your actions are aligned with your values, you think you can do this sustainably, your company values your behaviour and you don't really care about what your colleagues think of you then go ahead with it. Somehow, just the mere fact that you've asked this question seems to indicate that something about these actions feels wrong to yourself.