
Dealing with insubordination - software
https://www.softwareteamlead.com/getting-on-board-dealing-with-insubordination/
======
Clubber
>All the lead wanted was a single private variable placed in the class and the
amount of effort it took to get that accomplished was a multiple day
discussion. There are processes in place to get things like this removed. If
you are iterating and being “agile”, then you can remove it later realizing
your mistake, and if you code it right, then it will not be intertwined into
code so deep that is causes a delay.

Based on this explanation the lead wanted a quick hack put into the code and
the developer didn't want to write it (probably because it was a bad idea).

So here's how you solve that. Get the developer to find a solution to whatever
the problem the hack was solving. Give him a deadline. "If you feel this
strongly about it, find a solution by tomorrow morning, or we need to put this
hack in for this push."

Pretty simple. Going all micromanaging dictator who forces shit hacks won't be
good for your department short or medium term.

~~~
finaliteration
> Pretty simple. Going all micromanaging dictator who forces shit hacks won't
> be good for your department short or medium term.

The same could be said about questioning minor requests from someone who has
more experience than you do and who has a greater responsibility to deliver on
deadlines. Wasting hours of time over a single line is a great way to make
people dislike you for being so inflexible, especially if it’s holding up the
work of others on your team.

~~~
Clubber
If it's bad code, it's bad code. Good developers don't like to write bad code.
Any experienced, good developer has most likely worked on a shit codebase and
understands 1. that it didn't happen all at once, but trickled in and 2. it's
debilitating to the organization. If you force good developers to write bad
code, you probably won't have good developers much longer.

If I knew more about the circumstances, I could make a better judgement, but
to me it sounds like the lead wanted the developer to put in shit code and he
didn't want to. The thing about shit code is it costs 2x, 10x, 100x of
technical debt later. Remember the article is written from someone biased
towards the lead.

~~~
wolco
Senior developers know that wasting two days fighting would be better spent
elsewhere. This is an example of a midlevel programmer who can program but
doesn't understand the big picture. Probably the type of person to follow one
way of doing somethig and freakout on anyone who suggests something different.
This developer doesn't get it... they need a few more years of seasoning.

The lead is in charge of making those decisions. Having a working feature in
time for the sales demo is more important than some code purity.

They do not understand the difference between getting paid to do a task vs
creating a personal hobby project.

~~~
Clubber
>Senior developers know that wasting two days fighting would be better spent
elsewhere.

I disagree. Sometimes, yes, but most of the time, no. Two days fighting can
save years of maintenance costs (and I'm assuming productive fighting, not
fighting for the sake of it). Ever developed on a not-well-thought out
database model? No foreign keys? No consistent naming? Dates as varchar?
You're stuck with it. It not only causes more defects in existing code, it
makes enhancements harder and more prone to defects.

But it's hard to speak up on such things. It much easier, mentally, to just
say screw it and write the bad code, especially if someone is non-
confrontational by nature.

~~~
wolco
You are not stuck with those things. Converting dates or adding references or
changing the customer model or even migrating to a different type of database
are things you would normally do when you start scaling anyways.

The code doesn't have to be perfect aligned to some doctrine.

If you feel the need to fight back over a single private member variable delay
some important release the reasoning must be better than one day in the future
it, it will make development slightly harder. Refactoring is a good practice.

~~~
Clubber
>are things you would normally do when you start scaling anyways.

It is (sometimes but rarely fundamentally different refactoring) but when a
crappy schema has been built on for years, it is exponentially more difficult
to refactor, especially a live system with multiple clients and uses. The best
(and cheapest) medicine for that is to not inject crappy design in the first
place. Sometimes you have to, but it should really taste bad.

>The code doesn't have to be perfect aligned to some doctrine.

If the doctrine is not putting crappy / hacky code in the code base if you can
at all help it, I think that's a fairly standard doctrine.

>If you feel the need to fight back over a single private member variable
delay some important release

I'm not sure if the article said the discussion would delay a release or that
the release was important. All those absolutely do come into play though. If
they were in play, you'd think the dev lead would have enough respect for his
team to point that out.

------
Scarblac
The company I work for is Dutch (very egalitarian, consensus-based work
culture), hires only people with academic degrees (love to argue), has a very
flat organisation (very little hierarchical power to make anyone do anything)
and on top of everything else, it's a consultancy with a software development
branch at heart, and the programmers are told the same thing as the
consultants -- be visible, have an opinion, make it known, and so on.

So this is completely typical for every single ticket and the team lead is
powerless.

What works is: let the team know the planning, make the whole team feel
responsible for making the planning, ask this programmer to make this ticket
happen, let him come to the same conclusion as you regarding the planning
(argue), and then have him figure out how to solve it in half a day. He'll
probably also add the private variable, or come up with a similar way.

Alternatively, add the damn private variable yourself, if it's only a single
line.

Trying to force people to do things on a level of detail that is well within
the area they want to decide themselves doesn't work.

"Team lead" isn't "team boss".

~~~
le-mark
Subtitle of the blog explains a lot:

 _Views and insights on leading a software team through experience in military
leadership and on the job experience with enterprise level software products._

I've seen many, many prior military people utterly fail in the civilian work
force because, guess what? You can't just bark orders and expect to get
anything done. You can't belittle, berate, and batter civilians with words the
way leaders are encouraged in the military.

 _Front leaning rest postion, Move!_

 _Five zero, knock em out._

Good luck being able to type at keyboard after 50 pushups.

~~~
zeveb
I've seen many, many projects in the civilian workforce fail because, guess
what? Not everyone gets to be CEO and CTO.

Sometimes leaders are wrong, and sometimes those who should lead are tyrants,
but sometimes folks need to get in line and follow.

Different situations are different.

~~~
Scarblac
I've argued that in our company, _at least_ there should be someone on a team
who gets the official power to be tiebreaker, to just _make a decision_ when
some discussion of whether to walk around the park clockwise or widdershins
today just keeps going on on and on... But that's just not how it works here.

------
rjzzleep
I've had a fair share of this crap myself being the team lead at the time. I
didn't go yelling at the dev for not understanding that my contract said team
lead and the CTO failed to communicate that role or giving me the opportunity
to communicate it. I spoke with the CTO and asked him to clarify the roles and
gave him a clear choice. He decided against clear communication and I decided
to take more money elsewhere.

The problem is oftentimes not the individual being insubordinate. Oftentimes
the issue is that Roles and Responsibilities are not clearly defined.

This is especially an issue when one of previous colleagues on the same level
is promoted to the higher ranking position. It's an even more common issue in
big corp and govt. institutions.

> Implicit tasks are not always common sense.

There is no such thing as implicit tasks. There are implicit tasks, when you
sit in your garage and found a company and one guy is a marketing wiz and the
other a rockstar dev. You might even have a well working symbiosis then.
Everything beyond that needs to(at least some extent) be defined.

~~~
rjmill
>The problem is oftentimes not the individual being insubordinate. Oftentimes
the issue is that Roles and Responsibilities are not clearly defined.

This is entirely possible too. I just had an experience where I unwittingly
cut the technical lead of my team out of an important conversation simply
because I didn't realize he would care. I wanted to limit the scope of the
conversation because of time constraints.

I told him to his face in a meeting that I was trying to limit the scope of
the conversation. He was not very happy about that.

Needless to say, once I realized what a butthead I had been, I apologized
profusely, explained that I had misunderstood the situation, and promised not
to let that ever happen again. It ended up being fine after that, but boy did
I feel dumb.

Point is, don't just assume that new hires will automatically infer what
everyone's role is.

------
jstanley
> Lead: This is not a choice. I am telling you to do this.

> Teammate: You need to convince me.

I think the teammate's at least half right on this one. Nobody does anything
without wanting to do it. If you want somebody to do something, you _do_ need
to convince them. If they'll do it just because you say they have to, they're
still probably harbouring some resentment about it, which won't work out well
in the long term anyway.

At least this guy was big enough to stand up for what he believed in.

> Just write the less than 80 characters line to add the variable and move on.

If it's so easy, why didn't the lead just do it himself instead of making a
problem out of it?

~~~
watty
I disagree. Team leads are chosen for a reason and when they clearly ask for a
task, it needs to be done without the wasted effort of having to convince
them.

> If it's so easy, why didn't the lead just do it himself instead of making a
> problem out of it?

It's called delegation. If there are 15 easy tasks, a team lead can delegate
them out using his or her judgement and have them completed quicker than doing
it themselves. If each of those easy tasks has to go through a "convincing
phase" it's no longer worth it.

~~~
latch
A lead that squanders an opportunity to mentor isn't much of a lead.

~~~
watty
I didn't say that one shouldn't mentor or receive feedback. I actually think
if you disagree with the team lead you should let them know and then let them
make the decision.

If they hear your opinion and still go a different way, that's fine - roll
with it. It shouldn't require every individual on the team to be convinced,
that's a massive waste of time.

------
phkahler
There's a lot wrong with this situation. Without knowing the person involved
it's hard to say if they have an attitude problem, but it sounds like the team
lead does.

>>Who is right? No one is right, but the lead has the authority to expect
tasks to be accomplished when asked and has the responsibility of delivering
the release on time.

There is something wrong when one has to defer to their authority to get
things done. In this case it's even stated that there is no correct answer, so
why does the lead need to have it their way?

There's also the small problem of what was asked. It's hard for me to believe
that adding a private variable is actually implementing a product feature.
This smells badly of telling someone HOW to do their job rather than WHAT you
want.

And finally there is context. Sometimes when it comes to time pressure a
phrase comes to mind "a lack of planning on your part does not constitute an
emergency on my part." It would obviously be stupid to say that, but in _some_
cases it's the right attitude to have. It's not at all clear from this piece
what the overall context is, what the actual feature is, or which person is
being unreasonable.

I'm actually leaning toward the author as the problem. This need to blog about
a petty dispute over a variable declaration suggests that _maybe_ the person
not obeying orders could be pushing back against a larger problem.

TL;DR there's really not enough here to tell who the problem is, or if there
is really much of a problem at all.

------
DominikD
This is weird. Author wants me to agree, that I have to unconditionally submit
to someone because of their title. No ifs or buts, just do as you're told. I
worked with people who loved to manage like this and in every single case when
they asked for a wrong thing it was later developer's fault that he did
something (it's his name on the commit after all). On the flip side every
competent, cooperative manager I've worked with had no issue with people not
wanting to do something. But yeah, YMMV. Perhaps in some bizarre world "I
command you to do X" is the civilized way to talk to other people.

~~~
naasking
> I worked with people who loved to manage like this and in every single case
> when they asked for a wrong thing it was later developer's fault that he did
> something (it's his name on the commit after all).

So log your protest and the command in the commit message too.

~~~
DominikD
Telling people "I demand that you do it" or even "do it, or else" is a symptom
of a greater problem with said person. I don't see how waging battles with
this type of lead in commit messages is going to help me.

~~~
naasking
> I don't see how waging battles with this type of lead in commit messages is
> going to help me.

What a weird way to phrase it. The problem as stated is that the developer
gets the blame because his name is on the commit message. If you document that
you were specifically instructed to implement this commit, then that solves
the problem.

------
kranner
Something about using the word 'insubordination' and linking to a dictionary
definition that defines it as "not submitting to authority" and [being]
"disobedient" really rubs me the wrong way.

Authority etc. are implied of course, in a team structure where there is a
lead (and others are not), but if you told me to "obey your authority" in so
many words, I would have a problem complying very easily.

~~~
Clubber
I would say right now, good developers have more of an authority parity with
business than any type of employee has ever had, based on scarcity and
necessity. Hope it lasts.

------
seasonalgrit
Wasn't entirely sure if this was a sincere post, or some sort of unfunny
burlesque of some kind. Assuming it's sincere, then the author of this blog
post couldn't be more wrong about how to manage a software team. If a manager-
type started going full-on micromanagement on me ("add a private var to this
class now! rawr!"), bandies about the term 'insubordiation', and generally
believes they're entitled to my unthinking obedience, then congrats: you've
successfully convinced me to start floating my resume so I can get the hell
out of that shitshow. I'm an educated, experienced software engineer with
multiple degrees and life's too short to put up with that bullshit.

~~~
paulgrimes1
Well said.

------
tboyd47
The whole situation sounds ridiculous and the advice given is just awful.

A "team lead" should not be informing developers on the implementation details
of their ticket. The developer had every right to protest.

> If the individual is not a fit, then move him to another team that might
> have a different control style.

This is so backwards I don't even know where to begin. It sounds like the
advice is to break up a team just to show the developers "who's boss." I would
never want to work for this person. They put their own ego and control freak
issues over the stability and productivity of the team.

Also, it's a super weaselly move that instead of just going to the developer
in person and raising your concerns with him like a reasonable human, they
used their corporate clout to bypass the issue and move him to another team.
Is that acting like a leader?

------
Ensorceled
> Lead: This is not a choice. I am telling you to do this. > Teammate: You
> need to convince me.

I've reached the point in a discussion with a subordinate where I've had to
say "this is not a choice" multiple times in my 30-year management career.
Only twice has the person absolutely refused and only one of those times was
this part of the reason the person ended up being fired.

I'm amazed at how many times these kinds of ultimatums come down to some
strange, abstract principle: "I won't pollute my code with a global setting,
instead you're going to delay the release a couple of weeks while I re-write
the code and we re-QA everything." No, that's not what is happening.

At some point, it is my job to make the call. If you think it is your job to
make the call, you should find a job where it is your job to make the call.

I assuming, of course, your lead is not asking you to do something immoral or
illegal. Since I've been on the other end of that before.

------
Edd314159
When you have a team member being abrasive and insubordinate, sometimes that's
just their personality.

But sometimes it's not. Is there something about your culture that isn't
allowing them to make any of their own decisions, and they grasp for and fight
to the death to defend every little piece of autonomy they can get?

Disregarding whether the disagreeable team member is right or not - it's
entirely possible that when this happens, it is a symptom of bad management,
and not the fault of the employee.

------
SirensOfTitan
A team is not a fiefdom. Using "authority" to handle conflicts likely won't
lead to good results. Different people need different guidance, and overall
management seems poor at dealing with people.

Also: "[implementing] a private variable in a class" is not a "task". A diff
should be a single idea (i.e. have a purpose on its own). Adding unused code
with no purpose just makes it likely that code will stay dead forever. In
codebases I work in, an unused variable would be a lint error and that code
could never ship.

> If you are iterating and being “agile”, then you can remove it later
> realizing your mistake, and if you code it right, then it will not be
> intertwined into code so deep that is causes a delay.

It seems like the author hasn't worked with a large code base before. With a
constant pressure to ship, dead code can sit around in your repo for a long
while--and often good engineering initiatives aren't incentivized as much as
they should.

~~~
bitwize
> Also: "[implementing] a private variable in a class" is not a "task".

Haven't sit on very many task breakdown meetings, have you?

------
musage
> This is the short version of how the conversation, but suffice it to say
> that the teammate decided he was in control and wanted the team lead to
> convince why he should implement a private variable in a class.

The teammate decided they're an adult. And looking at the "military" tag I'm
not convinced the blog post author is.

> He isn’t a bad worker, but the relationship between the leadership style and
> his work style are clashing

The relationship are clashing? At this point, I'm really only interested in
the view point of the person who so far didn't even get to speak, because the
person talking about them I heard enough from.

------
CoolGuySteve
If the change is really so minor then it sounds like the employee is reacting
against micromanagement.

What kind of agency are you expected to have if minor things like private
variables are considered insubordination to authority? And then why would
anyone want to continue working under a regime like that?

The manager, presumably being more senior, should have the maturity to know
when to choose their battles.

I typically only intervene when I can see major architectural hurdles coming
up, but I often see my colleagues fighting these stupid battles as managers
and it's infuriating.

------
ndh2
_Views and insights on leading a software team through experience in military
leadership and on the job experience with enterprise level software products_

Okay...

Does this guy have any articles on software bootcamp where drill sergeants
scream at you to break you?

------
fogetti
Many people in this comment thread are assuming that a team lead has more
experience, or he is more talented then the devs.

I am sorry folks, but this is not how it works. In many companies the earlier
you arrive, the better chance you have to become the team lead.

Also nepotism is absolutely widespread in the IT industry. People just simply
assign tasks to people who they TRUST. And no-one can tell me that trust can
be quantified, because it cannot be.

Having said that I am not arguing that these things would be inherently wrong,
it all depends how the team lead handles it's responsibility. If he has
talent, he will make the team collaborate and get everyone involved.

If he is just a random guy assigned to a team for whatever reason and he is an
anti-talent then he will try to micromanage the shit out of everything and
everyone and will simply induce stress, burn-out and discontent.

Also it's a completely different point, but many people are assuming a "chain
of command", "subordination" and mindless self-abasement. But the thing is
that the dev only has to do as much as commanded by his contract/by the law.
If the contract is unclear, then well, the onus is on the employer to make a
better contract. So there are many unknowns in this story. But in any case,
implying or expecting something without communicating it towards the dev is
just simply unethical, unprofessional and lame.

Some other commenters also pointed out that if roles and responsibilities are
not clearly defined, then that's gonna cause problems. I fully agree with
this. And it's happening more often that not that companies hire people using
a generic form which basically outlines the companies rights in detail but it
doesn't say a single word about the employee's supervisors, expected skills
and tasks or his responsibilities.

And as I argued in another comment below, transparency solves many of the
problems which are raising from the failures I mentioned here. It just happens
to be more popular to be exclusive, restrictive, restraining and secretive in
management circles which is the exact opposite of being professional in my
book.

------
pavel_lishin
This is the first time I've encountered the term "BLUF". Turns out, it's the
equivalent of TLDR - "Bottom Line Up Front".

------
alex_young
This sounds like a missed opportunity to coach rather than fix.

What if the lead had discussed the business objective and problem and then
asked the developers to come up with a time bounded solution?

My guess: one of two things would have happened - the team would have arrived
at a better solution or they would have found the same need for the original
proposal. Either way everyone comes away feeling empowered and productive.

------
brianwawok
Sounds like you should try really hard to:

1) Not hire someone that is going to argue about every single decision

2) Fire them if you get to the case of 1.

I have worked with quite a few "arguers" in my day. They all made good points.
I am sure they were often right. But when it was 1v5 on the team for a
particular decision, and our scrum master was making us having meetings for
hours to resolve a stylistic difference that only 1 person agreed with.. blah.
I cannot think of a better way to kill morale of an otherwise good team.

Sure in an ideal world, the team would work together and make decisions. If
it's not working and one guy is sticking out over and over.. it's time to cut
your losses. I have never seen a construction crew where one bricklayer would
refuse to lay bricks a certain way, because he read a blog that another way is
better. Sometimes you just need to put your head down and do the task, not
make an argument about it.

~~~
Avernar
> scrum master

Your development process is based on micro management...

> hours to resolve a stylistic difference

so it's not surprising that there are debates about the one thing the devs
have control over.

~~~
brianwawok
Ya right, which is why I don't think in my own company I could ever see hiring
a scrum master. I get the point in theory, and I have met a bunch of really
great guys... but the process is just too much for my taste.

------
marcoandrade
In the military, leaders are taught to explain their guidance to subordinates
whenever possible. But sometimes, a Soldier needs to just be quiet and roll
out. Yes, this does require a Soldier to trust his leadership. It also
requires them to be a professional. It is not your job as a subordinate to
mentor/develop your supervisor. It is that team lead's supervisor. If I were
treated this way, that subordinate would lose some of his paycheck or be
forced to work many extra hours performing menial tasks.

Far more importantly, I would have lost respect for that individual. It's one
thing to ask for clarification (which is awesome), it's another to convey
blatant disrespect and unprofessionalism. No matter the circumstance or poor
leadership, you do not demean yourself like that.

~~~
icholy
This isn't the military.

~~~
marcoandrade
Thank you for the in-depth analysis buddy. It's a great how you addressed the
underlying point of the comment.

~~~
icholy
Lol you sound like a shit boss/manager.

------
golergka
Really depends on how exactly was it said.

Option one: team member says "I think this is a bad decision". Should lead to
a productive discussion, decision in the end taken by team leader. A person
who cares about quality of a product and can argue for his point of view is a
valuable team member.

Option two: team member says "I won't do it no matter what do you say because
I don't respect your authority as a lead". Get it in writing, get paperwork
done on termination due to insubordination (or whatever it's called in your
country), so that every potential employer sees the red flag next time. A
person who doesn't accept his role in a team and doesn't respect contract he
signed (which usually specify chain of command) shouldn't work in the
industry.

~~~
JoeAltmaier
So, every bad team lead results in permanent blackballing of everybody they
piss off? That's a dystopian nightmare.

~~~
golergka
If a team leader pisses you off and you think that they are inherently
incompetent, you can tell it to his boss, and if it doesn't work, ask for a
transfer to another team or resign. Telling him "I don't recognize your
authority" is a _really_ bad way to react to such a situation.

~~~
JoeAltmaier
People are human. These humans deserve better than draconian blackballing
because it offends somebody.

------
solipsism
Something tells me the other side of the story (told by the dev) would sound
very different.

------
LyndsySimon
> Lead: I need you to implement “X”. > Teammate: No. > Lead: This is not a
> choice. I am telling you to do this. > Teammate: You need to convince me.

There will be times, even as a junior team member when you strongly disagree
with a decision. I have always felt that there is a virtually unlimited supply
of people out there who can implement what they're told to implement, but that
if I wanted to justify the salary I wanted it was my obligation to share my
expertise by pushing back against what I saw as bad architectural decisions.

Early in my career, this didn't work out so well for me :)

I think I've figured it out by this point. There is a balance to be struck
between "you're the boss" and "I don't think this is the right path" \- and
that balance differs from person to person. There are some key factors that
remain constant:

1\. It's not personal. I'm careful not to imply that something is wrong with
the person who made the decision, merely that I disagree with the decision. If
it feels like egos are getting involved - including my own! - I drop it

2\. Organizational structure exists for a reason. I'm very explicit in
acknowledging that I will perform the task as given to the best of my
abilities if that's what is asked of me.

3\. Keep it private. Challenging your team lead in a meeting with a half-dozen
other developers is a Bad Idea.

Basically, I don't think it's too much to ask that your leadership treat your
professional opinions with respect. If you are working in an environment where
the above seems impossible to you... you should change your environment.

------
oceanghost
The author is giving us zero contextual information. That is a red flag in and
of itself.

The variable is a proxy for a deeper issue which the author is purposefully
withholding.

------
DanielBMarkham
Key question: how are you going to handle things when you know you're right
but the team/lead votes the other way?

Some folks, once they know what is right, will never do anything but that.
Avoid these people. Some folks are so apathetic they agree to anything. Avoid
these people too.

There's an old phrase "Strong opinions, lightly held". Have good and powerful
reasons for the viewpoints you own. Defend them -- at length if necessary --
and passionately argue the merits of your view.

But at the same time, get a grip. Your job as a professional is to both have
strong opinions about quality and to be able to dance to whatever song is
playing. At some point, sure, the environment could be so bad that you should
take a walk instead of staying and putting up with it. That's one of the
values they hired you for. But whether or not to have a private variable is
not that point.

ADD: I think this is just as important, _more important, actually_ for leads
and managers as it is for workers. We model the behavior we want to see. If
you're hard-headed and have a take-no-prisoners attitude, or if you're
apathetic and jaded? Your reports see that. They copy it.

~~~
zeveb
> Your job as a professional is to both have strong opinions about quality and
> to be able to dance to whatever song is playing.

Yeah, this is really key. I have some very strong opinions about quality
processes in software development. My employer and my team lead are paying for
my expertise and advice, and I give it to them. But at the end of the day, if
they want to pursue what I believe is an unwise course, I have a decision:
follow, or resign. A professional doesn't spend his time sniping & griping: he
knuckles down and produces — or he leaves.

We can't all be special snowflakes.

------
software
As the author of the post. Just a couple comments...

1) I am referencing a team lead not myself. 2) I still agree that no one was
right or wrong in this situation, and it had the right intentions to stir up
discussion to see what people thought about it. 3) If you have reference to
other posts that I have put on my site than you will see that as a leader you
have to surround yourself with people who are better in certain or all
verticals than you.

Check out this post ([https://www.softwareteamlead.com/lead-by-example-
characteris...](https://www.softwareteamlead.com/lead-by-example-
characteristics/)) on the characteristics I strive to exemplify.

------
Mz
I am reminded of this: [http://edw519.posthaven.com/it-takes-6-days-to-
change-1-line...](http://edw519.posthaven.com/it-takes-6-days-to-
change-1-line-of-code)

But I also have the thought that in the military, the person issuing orders is
also responsible for things if they go wrong. If his orders are bad, he takes
the fall for them. I wonder if that is the case here. Or is it a case of "Do
as you are told, and then take the fall when it breaks our system."

If so, you have deeper problems than one guy saying "Nope. No can do."

------
phugoid
From the article:

> He isn’t a bad worker, but the relationship between the leadership style and
> his work style are clashing.

If refusing to take orders doesn't make you a bad worker, then what does?

I've carried out orders that I didn't agree with many times. Disagreeing with
your boss respectfully is a bit of an art, especially when the person who is
likely to suffer from a bad decision is yourself. But at the end of the day,
this is why we call it work instead of play.

One strategy that seems to work is: be diligent, get things done well and on
time, and gain the trust and respect of your team and managers. People will
listen to you more when they stop suspecting you of shirking work or just
being argumentative. Instead of arguments, you can have conversations and
sometimes you might even prevail.

~~~
Clubber
It depends if you want "yes" men, or people to disagree with you. It might
sting sometimes, but people who are willing to argue with you are much more
beneficial to the organization for the most part. (I accept that some people
just like to argue for the sake of personal satisfaction, I'm assuming this
isn't the case here).

Remember, they aren't making widgets, they are engineering software; it's a
high knowledge, high skill task.

~~~
ygaf
>It might sting sometimes, but people who are willing to argue with you are
much more beneficial to the organization for the most part.

>The thing about shit code is it costs 2x, 10x, 100x of technical debt later.

I'm on board with all those things, but bear in mind the insubordinate guy is
alleged to just think it's 'bloat', not that he thought it would undermine the
whole architecture of the code (and it's easy to imagine 1 additional class
variable not doing so). Bloat is often a problem of autists.

~~~
Clubber
Yes, that's a good point. The facts are scarce and it's hard to tell what's
going on, so I can only make assumptions. I'm making assumptions based on my
experience. If I bother to speak up about something, I think it's worth
talking up about. Could it be the guy was just being a prick? Absolutely.

------
p3nt3ll3r
I had a chairman of a company scream that if we did all not do exactly as he
said, he would consider it insubordination. I found another job, then sent him
a private message to go fack himself.

------
bitwize
> Lead: This is not a choice. I am telling you to do this.

> Teammate: You need to convince me.

Lead: If you don't do it, you will be fired and replaced with someone who
will. Convinced yet?

~~~
seasonalgrit
When you have to threaten someone on your team, you've reached rock-bottom as
a manager; all you're really accomplishing is convincing your team to leave
for greener pastures.

~~~
bitwize
You know how Mao said power flows from the barrel of a gun? In the office,
power flows from the threat of job loss. It's the threat implicit in _every_
executive decision.

