
Ask HN: Do you work with dogmatic, stubborn developers/sysadmins? Are YOU one? - hoodoof
For some reason there seems to be a very large number of highly dogmatic, stubborn and difficult-to-get-along-with people who work in development or as sysadmins.<p>People like this get grumpy and sulky when the technical decisions aren&#x27;t what they agree with. They might even shout or yell at other people to get their own way. They&#x27;ll deride the technical opinions of their teammates so they that can be &quot;right&quot;, and &quot;the winner&quot; of the technical point in question.<p>Such people find it hard to empathise with others and think they they are the smartest and that their opinion is more valuable than everyone else&#x27;s.<p>They value &quot;the right technical decision&quot; over human relationships and it doesn&#x27;t seem to occur to them that the right outcome might be the one that makes someone else happy, or is the most diplomatic, even if it isn&#x27;t &quot;technically right&quot;.<p>Have you encountered many people like this in your IT career?  Do you work with people like that now?  Are YOU a dogmatic, stubborn and difficult person?<p>How do these people impact your technical team&#x27;s work environment?
======
stephenr
This sounds very much like you're advocating for the exact thing I was talking
about when I coined the phrase "Kumbaya approach to Project Management" a few
months ago in a HN thread. In short, you favour "everyone's opinion is valid"
over technical correctness.

When you are dealing with a highly _technical_ field, such as software
development or server/infrastructure administration, why on earth would you
not value being _technically correct_ above all else?

If five people on your team think it's ok to accept logins via plain HTTP and
one person says "uh no, you need to use HTTPS" would you ignore what he or she
says, because the other five disagree?

In my experience, the highly opinionated people who are willing to fight and
argue to make their point are usually the ones you need to listen to.

If someone don't care (or doesn't know enough about the subject matter) enough
to argue at length for their point of view, why would you listen to anything
they have to say?

~~~
tacone
That's a false dichotomy. You basically say that the stubborness usually comes
from a deeper understanding, which is a ungrounded assumption at the very
least.

Lets reverse your example: _If five people on your team think it 's ok to
accept logins via HTTPS and one person says "uh no, HTTP is enough, and also
cheaper and faster" would you ignore what he or she says, because the other
five disagree?_

I've seen countless people arguing even before looking at the code for
example, or advocating software solutions they never tried.

I've also seen people frustrated enough by the pointless arguing that happens
in some workplaces to just give up on their opinion and switching to the try-
to-limit-damages mode.

The problem is one of character and team collaboration, not a merely technical
one.

~~~
stephenr
> Lets reverse your example

I was specifically replying to this, quite frankly terrifying part of the OP:

> They value "the right technical decision" over human relationships and it
> doesn't seem to occur to them that the right outcome might be the one that
> makes someone else happy, or is the most diplomatic, even if it isn't
> "technically right".

~~~
tacone
gotcha

------
noir_lord
> People like this get grumpy and sulky when the technical decisions aren't
> what they agree with.

Imagine been a life guard, telling a mom there is a shark off the beach and
not to send the kids in the water, having the mom then send the kids in the
water and _then blame you for the shark eating them_.

That's pretty much the life of a lot of more experienced developers.

> They value "the right technical decision" over human relationships.

That's because if the wrong decision is made those human relationships go to
shit when they get blamed _anyway_.

> it doesn't seem to occur to them that the right outcome might be the one
> that makes someone else happy.

This isn't flower arranging, there are a limited number of solutions that will
fit the requirements, if one of those can include "makes sunshine and unicorns
appear" cool.

> Are YOU a dogmatic, stubborn and difficult person?

I don't think so (but then how would I know), I've never been fired in my
entire life and survived 5-6 rounds of redundancies so I can't be that hard
work.

~~~
kasey_junk
Interestingly, I feel like the more experienced I've gotten the less I find
there to be "technically right" decisions. There are just trade-offs and
picking the set of trade-offs that make the most sense at the time of the
decision making is the best you can do.

That decision may turn out to be wrong for a wide variety of reasons, most of
which do not invalidate the decision _at the time it was made_.

When I was less experienced, I thought there were _right_ answers and I strove
to get to them. Now I just want to be explicit about the trade-offs I'm
making.

~~~
ocdtrekkie
I can agree with that. Every option is likely to have pros and cons. If you
know what they all are, you can make the choice based on which cons you can
live with, and which pros are the most important to you.

------
tinco

       They value "the right technical decision" over human relationships and it doesn't seem to occur to them that the right outcome might be the one that makes someone else happy, or is the most diplomatic, even if it isn't "technically right".
    

The question you should be asking is: A coworker tells me or my coworker that
we're wrong, and it hurts our feelings, how do we deal with it?

I've been in this situation a lot. I'm a social and diplomatic guy with a
passion for programming but I've also been nonchalant or even careless and get
told off for it a lot by colleagues with superior discipline and experience.

It hurts when you think you're good at something, and someone points out a
flaw that in retrospect is obvious or even dangerous. For me it helps to think
highly of the people who gives me the criticism, even if I think they're dull
and over-disciplined.

I strive to one day be as cautious and knowledgeable as they are so code I
write will be as reliable and robust. And ideally someday I'll look at their
code and point out their negligence.

In a team, I would try to publicly compliment the grumpy programmer on his
feedback, and initiate conversation on how to set the tech straight. A
positive reaction will temper his grumpiness and make him rethink his
attitude, they might even backpedal and say 'well its not _that_ big a deal'
when you list the downsides of the 'right technical decision' as hurdles you
are planning on overcoming. Once you've accepted someones feedback fully, it's
much easier to negotiate.

Note that you should only do this when it is 100% the case that this person is
technically right.

------
a3n
I've seen those people everywhere, for decades. They suck.

I don't think I've been dogmatic. Maybe stubborn. I have been a very difficult
person, and that almost cost me my job.

I've been on antidepressants for awhile, and I have a completely different
inner and outer life. Besides my mental health, it's allowed me the space to
see that most decisions don't matter all that much. Everyone wants to get the
job done, and whatever is decided, the job will get done, for better or worse.

It's also taught me that when other people suck, it might be because of other
issues. For me it was depression. Other assholes may be depressed, or have
some other condition, or some stress in their lives that they aren't currently
able to handle well. They may be overwhelmed by something.

Or they might just be assholes. But it doesn't matter much either way. Find a
way to live with them or leave.

------
viraptor
I think the questions imply one side of the argument. I thought there's one
reasonable side to this argument. Then I was a stubborn person one day. Why?

Because someone wrote an SQL query with string interpolation of variables and
no escaping. Why? Because the values at that time were actually coming from a
limited set and were safe to provide that way. Yet I argued that it should be
a prepared query anyway, so that we avoid it potentially exploding in the
future.

Was he right that it doesn't matter at the time - yes. Would I be the
annoying, stubborn, difficult person who knows better again in a similar
situation? Yes! And I know some people will be angry about it while others
will agree with me. That's life.

~~~
jerf
There's a whole range of possibilities here. Sometimes you get the strong-
willed person who has perfectly sensible arguments and may even be fully
technically correct, but for non-technical reasons you can't go with their
choice, and that really bothers them. Sometimes you get the strong-willed
person who has a choice in mind, and doesn't have strong reasons, just strong
opinions. Sometimes you have the person who thinks they know the right answer,
but a senior person is fighting with them because their experience tells them
there's still a problem tomorrow even if it's all fine today. And sometimes
you've got someone who is the very definition of fair and rational fighting
you tooth and nail because you are trying to do something very, very stupid.

And sometimes you've just got yourself an asshole.

It can be hard to tell which is which from someone's self-report. Presumably
hoodoof (the original poster) has one or more people in mind which prompted
hoodoof to write this, but from a one-sided view we really can't tell which is
which.

Of course, in the end, I'm not aware of any career path which is populated
solely by happy, healthy, well-balanced people that everyone loves to spend
time with. Not even therapists or the clergy.

~~~
desbo
Well said.

------
tvanantwerp
I think there's an important difference between a person who needs to be
right, and a person who is right and refuses to allow sloppy work to
jeopardize the company. The former certainly suck, and you'll find them among
any department, or among your clients, or even in your own family. The latter
are exactly who you want to be working with.

~~~
a3n
Yes exactly. The OP was asking a social question.

noir_lord said "[Having to argue against less experienced people is] pretty
much the life of a lot of more experienced developers."

Hopefully an experienced developer has gained the ability to advocate his
position without being a shouting dick about it. It's the shouting dick that I
think the OP was asking about.

Personally, no matter how right a shouting dick may be, I tend to shut down
and tune out shouting dicks. It's not my responsibility to find the diamond in
a flow of shit. Stop the shit and I'll consider your diamond, and be grateful
to learn from it, even if we don't happen to pick that particular diamond.

Someone else mentioned kumbaya project management, which I agree is the other
extreme and just as harmful. It's a way for managers and individuals to ignore
their responsibilities.

------
MrDosu
Remember you are in a business. It exists to make money, not to be a form of
kindergarden (yeah I am one of those people when it comes to producing the
best possible outcome to the company). Also being 'technical' not equal
'grumpy' and 'sulky' does.

At parties I'm pretty fun though.

~~~
gargarplex
You keep a pair of birkenstocks in the car?

~~~
MrDosu
high heels mate... out of cork

------
jorgeleo
Protecting personal feelings over the correct technical decision is the wrong
thing to ask of someone that is hired to make the correct technical decisions.

I am dogmatic, stubborn until proven wrong, and I can be perceived as
difficult if I know that the product/consumers will be sacrificed only so
sensitive people feels better.

Having said that, there are ways and ways to discuss differences. There are
many ways to deal with conflict resolution.

So far, every time I have been asked to come back and train the rest of the
team.

------
Mithaldu
Technical decisions are not meant to make anyone happy unless it is the
customer.

That said, dogmatic people CAN be an issue, but it is important to recognize
why, so things can be explained to them.

Typically technical decisions are a trade-off between cost now, and cost
later, and people dogmatic about technical decisions are happy to incur large
cost now, if it means reducing long term costs.

In doing so they however often overlook that the budget may not support the
now-costs they wish to incur, either because right now there it is too small,
or because the expected profit is too small.

Upon explaining this clearly they often remain unhappy, but become willing to
accept things for how they are.

------
mariusz79
You're advocating political correctness instead of engineering. That's wrong.

And perhaps it's you who's wrong and stubborn and that's why people with more
experience need to scream at you to get their point across?

------
skc
Heh,when I was a junior dev we had a senior guy on our team who would stay
after hours and refactor literally every line of code our team of four devs
had written that day.

What was even more infuriating than his condescending smugness about it is
that he was a really, really brilliant developer, so you couldn't really win
an argument with him over it. His code was indeed better, but never enough to
justify his being such a prick about it.

Also, during planning and architecture discussions he wouldn't say a word,
just go and rewrite everything we discussed.

I left for another team after about 3 months of this.

~~~
pessimizer
If he had time to consistently rewrite all of the code to a better standard
that the _entire team_ produced while also covering what he himself was
responsible for, he was probably working in hell. That shouldn't be possible
unless the code was generally pretty bad.

> Also, during planning and architecture discussions he wouldn't say a word,
> just go and rewrite everything we discussed.

Wild-assed speculation here, but if he didn't think that the rest of the team
would listen to his expertise (which you admit was strictly dominant over the
rest of the team) and didn't think they were qualified to argue with them
about it or teachable enough to learn from him - that could lead to a strategy
of silence and just fixing it after everybody else was done.

There are some things that one just can't argue about with some people without
it being a complete waste of time.

If he was basically running the show and ultimately responsible for the high
quality of the product, IMO he probably should have been tested as the manager
of the team. Being able to dictate the standards of the final product would
remove the need to argue, and require the team to learn what he wanted them to
learn.

> I left for another team after about 3 months of this.

If you were consistently wrong in your disagreements with the best member of
the team and instead of using that as motivation to improve, it simply
resulted in (traditional anti-egghead/smartypants) rage at the person who had
the nerve to be better than you at everything, it was probably better for
everyone.

~~~
skc
No, I left because he had poor interpersonal skills. I'm a senior developer
now in a position similar to his and I would never behave in the manner he
did.

I enjoy mentoring junior devs and I can't recall this ever being at odds with
getting shit done correctly in the end.

------
pnathan
> They value "the right technical decision" over human relationships and it
> doesn't seem to occur to them that the right outcome might be the one that
> makes someone else happy, or is the most diplomatic, even if it isn't
> "technically right".

Math is immutable. Feelings aren't.

I'd rather work with a guy driven to be technically correct and ruthless about
describing why than someone who throws garbage in or _allows_ garbage in, just
to make me feel better about myself and have a better relationship.

~~~
awinder
This can't be an "all or nothing" proposition in either case. There are
technical decisions that are absolutely worth fighting for, that would be
pretty devastating for the product or the company, and you're right, in those
cases, you might feel like you have to fight against the preconceived mood --
but even then, keeping account for feelings, because these are the people who
are going to need to build your "vision". Compassion without compromise is a
real thing.

In other cases, you need to keep in mind personal biases, and also keep in
mind the pyrrhic victories are a very real thing and a very real danger, even
potentially catastrophic in certain environments. Hiring an engineer, when you
figure in staff costs in interviewing and possible recruiter fees, can cost 5
figures easily. Lost opportunity costs in training and losing corporate
knowledge can push those figures even higher. Always have a good understanding
of what you're doing, what the consequences might be, and whether your issues
are worth those consequences.

------
dsmithatx
I've been working with Linux since 1994 and my last job was over 8000+ systems
in 12 Datacenters. Currently I work at a hardware company and we develop
Android for the hardware we create. Daily occurrences are developers insisting
that Unix files must be owned by certain users and that permissions must be
777 on CIFS shares. When I got here they all had admin/root and open ports on
the firewall inbound for no apparent reason. We are in a small building and
they don't get why we can't add more 40 core Xeon servers to a tiny computer
room. They modify the Jenkins build server and then get bored and move on to
something else. Thus the releases we have to deliver every Wed. and Fri. are
broken come Wed. and Fri. morning.

Most of these guys are Windows guys with 3-5 years experience using TFS. They
don't understand why we can't just buy all Microsoft Products when are budget
is allocated to getting them Jira among IT needs. They think we should
implement LDAP on everything instead of delivering to customers who are paying
us millions. Meanwhile I've got to do IT, Linux Engineering, Devops and manage
100+ developers in India in only 60+ hours per week.

You wonder why I value "the right technical decisions" and get grumpy? Oh but
I don't sulk I just take away access and tell them to go write code and stop
breaking the infrastructure. In my off hours rather than sleep I'm setting up
a Cloud environment on AWS to provide sandboxes to devs in India and provide
CI. I'm not dogmatic in anything, I believe in the right tool for the job and
the most efficient way to get work done properly. Since clients pay for our
T&M they appreciate me and I got a promotion on my 9th week. Now that the
developers are writing code and don't have to think about IT needs there is no
problem.

They've learned to appreciate doing thing "technically right". That means to
me using the tools you have to provide scalable infrastructure and making sure
deliverable are always met. I've seen many companies struggle for years to
turn profit only to go borrow more money. I learned from those mistakes and my
last companies revenue doubled to 300 million in one year after 20 years in
business. My current company had one project three months ago and we now have
10 starting up. We should have 10x revenue in the next 2 years.

~~~
a3n
So you're clearly not the guy the OP thinks he's talking about. :) I've always
appreciated your brand of admin+.

------
johnnyfaehell
> They value "the right technical decision" over human relationships and it
> doesn't seem to occur to them that the right outcome might be the one that
> makes someone else happy, or is the most diplomatic, even if it isn't
> "technically right".

No we're paid to do a job. The right outcome is the one that achieves that
job. Making you happy while you implement something that will cost the company
money isn't the right outcome.

------
bitdeveloper
If you are the one getting a call at 3am when something breaks, your opinion
_should_ matter more than someone else's.

Also, I find it strange that you put "the right technical decision" in quotes
here. Are you thinking of specific instances where (perhaps) you didn't
understand why someone was being stubborn about a choice, so you didn't value
their stubbornness? Maybe their reasoning is sound, but their articulation of
the reasoning could have been better.

People who insist on 'their way' for no reason are one thing. People who
insist on the right way, because they have dealt with a lot of problems in
their careers from doing things the wrong way, are another. The first is a
detriment, and the second is an asset. You have to be able to tell the
difference.

But if you're dealing with people who are being difficult for the sake of
being difficult, that really does suck.

------
lnanek2
Unfortunately, I've been the dogmatic person in a lot of cases. Often the feel
good viewpoint is just clueless and going to lead the company into real
problems.

I was recently at a company that was working on a custom AOSP build. Their
engineers had no clue what the repo tool used to download AOSP source was and
every day started arguments about how they wanted to replace it with git
submodules and things like that. Generally so they could do something the repo
tool already did, but they just didn't know how to do using it, such as
documenting the sha1 commit hashes used for a particular build.

If they had tons of engineers, fine, start rewriting core tooling, but it just
made no sense at all for a small startup with strong time pressures for
shipping and few engineers. Every other company from Google to drivers to
system on a chip companies is using repo so making their own incompatible
submodule based method would have 1) taken them a long time to reconfigure
~60GB of source code into a different format 2) made it really tough to bring
in later changes from the old format 3) made it really tough to do things like
integrate drivers and other code which typically ship with a README for how to
integrate into AOSP repo manifests.

Most of the people pushing the submodule rewrite had never even managed to
build AOSP using repo in the first place, so their estimates and explanations
usually made no sense. Yeah, it would have been the feel good solution to let
them stupidly make their attempt and fail or waste a month of time, but that's
going to hurt the company too, isn't it?

------
ta119a08
In almost all cases, it's not that they're dogmatic, stubborn, or difficult
just for the sake of it. Don't make it personal and imagine them to be poor
empathizers or know-it-alls.

By shouting and getting frustrated, they're really just demonstrating that you
and they have poor communication skills - in both directions. They either
aren't actually understanding the broad requirements for the decision being
made, and/or aren't really articulating why their take on it really is the
right way to do it. They have the confidence to think that their solution is
the right one for the problem as they understand it -- which is why they get
loud and forceful -- but don't make legitimate progress in decision making
because either the problem or solution just isn't making its way across the
table effectively.

Poor communication skills are indeed very hard to deal with and rampant among
people across all divisions. They may be the ones who are having a hard time
regulating their emotional investment into the debate, but there are things
you can do to make them more comfortable and better heard.

------
Mimu
First I think your "problem" is more with the attitude that the actual point
of these people. There is nothing wrong with being right, quite the opposite,
however it is wrong to hurt somebody feeling or completely ignore them because
you happen to be right. We are not robots, if you can't convince people that
you are right when it is the case, either the dude/girl in front of you is
dumb as fuck or you are the problem.

Personally if the guy in front of me is right I just agree with him and I
learn something in the process so it's cool.

If I'm the one being right and the others don't want to listen, I just say my
opinion and my arguments and the fuck with it, I won't argue forever we are
adults not kids, I couldn't even play this game as a kid, boring as fuck.

Granted I NEVER encounter situations like this, usually people listen to the
guy being right, if a compromise has to be made (quality vs. time to release
for example) then we do it, I never worked with childish people and probably
never will as I would most likely leave (if possible of course).

------
zippy786
> People like this get grumpy and sulky when the technical decisions aren't
> what they agree with. They might even shout or yell at other people to get
> their own > way. They'll deride the technical opinions of their teammates so
> they that can be "right", and "the winner" of the technical point in
> question.

This seems like someone who is not making technically correct decision but
still wants to be the winner. In this case, I actually think it's good that
people would fight such stubborn people who are not right and still want to
have their way. There are a ton of those kind of people out there.

> They value "the right technical decision" over human relationships and it
> doesn't seem to occur to them that the right outcome might be the one that
> makes > > > someone else happy, or is the most diplomatic, even if it isn't
> "technically right".

This sounds like the case of ethics. Do you work to make someone happy or do
you do the right thing.

I both the two cases, technically correct decision should be the way to go.
Otherwise you are compromising work ethics and then you get into the ugly
office politics arena where you are only working to make people happy without
caring about the architecture, tools that could benefit the software.

I might be a difficult person few years back, but today I give up and see that
not many people are passionate about software as I am. For many it's about
family, progressing their career and not about software and its users, which
is what it should be. I have also come across a lot of people who have tried
and succeeded in making the wrong technical decisions and still got the
promotion. After nearly 10 years, I think software industry has become an ugly
place because now it has too many people who are pseudo software lovers.

------
toigo
Ah yes the old "We're not arguing about how to do it, we're arguing about why
you don't want to do it my way, which also happens to be the right way!"

Being a good software engineer is also about being able to articulate why a
particular solution is the correct one and gain consensus rather than forcing
a decision on people.

~~~
Too
Oh yes, most other comments here seem to assume that the stubborn guy is
actually right technically and objectively, many times they are not, many
times there is no right or wrong and many times there are multiple right
answers. NIH is one effect of it and you can see it each day here on HN with
new js frameworks popping up all the time, half of them essentially doing the
same thing. If you haven't experienced it, it can be hard to believe but NIH
can be observed _within teams_ also, with certain individuals always wanting
to do things their way, often deciding that before they even looked at the
solution the others have come up with.

------
charlesholbrow
This happens when someone's job is deeply tied to their identity. I find that
people who have a separation between their self-identify, and what they do for
work are less likely to get defensive when their technical "correctness" is
questioned. People who suffer from job-identity are also more likely to adopt
the "You don't understand why I am right, because I am smarter than you"
stance.

If it feels like someone who questions your opinion is attacking you
personally, take a step back, and remember that you won't convince anyone you
are correct by insulting their intelligence.

------
gnoway
Yes. Yes. Yes.

It would be ideal if everyone was pleasant and accommodating of everyone
else's ideas at all times. There are usually ways to 'win' or otherwise arrive
at the correct solution without having to browbeat everyone into submission.
IMO the people who can do this tend to be good at a lot of other things; they
are just talented people, and in my experience end up being the 'good' higher
level management and technical leadership.

That said, I think you are seriously oversimplifying the work environment.
People are frequently overworked; or participating in a group where other
people are trying to make decisions they don't have the experience to make
(but don't realize it); or are having decisions made in front of them about
the effort they will expend towards x, without their input, by people who do
not understand what they are asking and/or don't care; or are otherwise not
being given the level of respect they deserve. Consider that some of these
people take a lot of pride in what they do and are personally invested in the
success of their work. Consider that over time, in this situation, these
people may become grumpy and combative.

And that's just in the work environment. I don't personally have a work/life
balance, but other people I know do have this and sometimes their personal
troubles bleed over into their work behavior. We're not all able to
compartmentalize.

This is a long-winded way of asking you not to jump to the conclusion that
there is something wrong with the personality of your grumpy coworker.
Consider that maybe it's an effect, and that you could even have helped cause
it.

------
emmelaich
IT operations will be seen to be responsible for something that was thrown
over the wall by developers months ago. And the developers have moved on.

In this all too common scenario there is a lot of value in being conservative.

That said, I do agree that it goes too far, and the occasional sysadmin cam be
most unpleasant.

------
JDDunn9
What's more frustrating are the people who are dogmatic and have the
technically wrong solution. When things get done a certain way because
everyone is just tired about fighting about it and the most stubborn person
wins.

------
solve
At low-end jobs only. The high-end, most desirable, generally highest wage
jobs absolutely do enforce a type of "no asshole rule" that prevents hiring
these kind of people, and fires them fast if they're discovered later.

It's MUCH easier to find these kind of low-end people who are looking for
work, since it's so much harder for them to get a job. That's the only reason
they're so over-represented, versus how many there really are.

Note that sometimes entire cities become filled with bad-behavior people, as
almost all of the good behavior people move to a different city. Look at
whether your city has a high emigration (moving out) rate among top-performers
in your industry. Do the most career ambitious people tend to move away from
your city, or move to your city?

------
Apleks
For the record, this is the definition of a BOFH: Bastard Operator From Hell.

~~~
noir_lord
No mention of a cattle prod so more PFY I think.

------
zhte415
> highly dogmatic, stubborn and difficult-to-get-along-with people

Not a problem. They have a way of doing things. That is their way. If it is
wrong, how do we persuade them?

> They might even shout or yell at other people to get their own way.

Not good. It becomes a personal problem, and people forget their roles as
problem solvers, and turn it into becoming winners.

> Such people find it hard to empathise with others and think they they are
> the smartest and that their opinion is more valuable than everyone else's.

Key word here is 'opinion'. Can it be changed to fact rather than opinion?
Opinion is personal. Break it down and go back a/several steps, to get logic
out of the opinion. If they're getting personal, as above, this may take hard
tactics, but being non-personal is key. Open questions, act as the idiot if
you're in a position of authority.

> They value "the right technical decision"

Great. They're committed. They want the best answer, and rationality is the
appeal [key - 'from their perspective']

> over human relationships

Bad. Perhaps they're engrained and don't recognize other interests. Take the
conversation back and get them to focus on long term interests. This can be
interesting, as often you may find the 'suborn, non-team-player' is trying to
act in everyone's interests, they've just made it a personal 'win' and others
don't recognize they recognize the win-win but are so engrossed they don't
express it (or there's a small thing they're afraid of giving up).

> the right outcome might be the one that makes someone else happy, or is the
> most diplomatic

Negotiation is not win-lost. It is win-win. Often the term 'diplomatic' puts
someone in the losing corner "give this one up for the team, we'll win at
something else". That is not diplomacy. Diplomacy is recognizing there is a
problem for everyone and giving something up is not a good option. Stick to
facts, logic, and encourage the exploration of everyone's long term interests.
Remember, you're problem solvers. "Technically right" often is right.
Information is key here - is someone unaware of a constraint in budget,
personnel, timeline, or other? Lacking information makes one feel weak, and
emotionally responsive.

> How do these people impact your technical team's work environment?

I try to impact theirs. The above is not wishy-washy. It is not focused on
making everyone happy. It is focused on people acting as problem solvers and
being tough on each other, while not getting dogged down on specifics to the
extent long term interests are ignored.

Source: Experience and reading. Do read 'Getting to Yes', a seminal book (for
me) and try some negotiation exercises with the team. Alternate who plays the
trainer. Awesome learnings within.

------
anon987
This has been posted and discussed several times on HN and I consider it to be
the best approach:

[http://www.kitchensoap.com/2012/10/25/on-being-a-senior-
engi...](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/#)

I'm not here to "win", I'm here to implement the best technical solution.

------
michaelochurch
You're missing one side of the equation. Some of those technical decisions
matter a great deal. Some don't, but language and tooling choices affect
careers. If we (at hypothetical company X where I work at a given time) become
a Spring/Hibernate/POJO/VibratorVisitorFactory hellhole, there is no place for
me. Over time, that means that I don't have a job. So, damn right, I am
personally invested in fighting that garbage before it gets in. Same when it
comes to that trendy "Agile"/Scrum shitshow.

Am I going to tell a front-end engineer with 15 years of exprience that he has
to use PureScript because I, personally, think JavaScript is a poorly-designed
language? No. That would be dogmatic. I generally prefer letting domain
experts call the shots that affect them. It's about getting _the right_
decision, regardless of whether it's _my_ decision, and I may not have all the
information.

There are times to step back and let someone else call the shots, and there
are times to stand your ground and fight. Make no mistake, though: promotions
and demotions and firings result from these decisions and their long-term
consequences, so getting them right _really_ matters.

~~~
budu3
>Same when it comes to that trendy "Agile"/Scrum shitshow Honest question.
What alternative would you suggest?

~~~
michaelochurch
_What alternative would you suggest?_

Hiring adults and trusting them to get their work done.

~~~
icedchai
This is far too pragmatic.

We all need babysitter "scrum masters" updating poorly written "user stories"
and doing "bug grooming."

Can we have a retro, please? Now it's time for planning poker!

Are we still in junior high? I gotta laugh. Why do people put up with this
bull?

~~~
michaelochurch
_Are we still in junior high? I gotta laugh. Why do people put up with this
bull?_

Because software engineers are terrible at managing their own social status,
both individually and collectively.

Social status determines how your work is evaluated, whether you are punished
or rewarded for taking initiative and working on what you think is important,
and how often you are held accountable for short-term results and visibility
into your work. Manage your social status poorly, and you'll get daily status
pings (the other meaning of "status"). Manage it well, and you can work on
whatever you want with a low level of interruption.

However, our industry is full of young, delusional people who haven't been
burned (i.e. had difficult life experiences) yet and still believe in the
corporate "meritocracy".

------
pif
> it doesn't seem to occur to them that the right outcome might be the one
> that makes someone else happy, or is the most diplomatic, even if it isn't
> "technically right".

If it isn't "technically right", it isn't right. Nothing to add.

