
Ask HN: What are some B.S. tricks management pulls on naive developers? - kbrannigan
As a company gets older it seems like politics are inevitable, no matter how hard or well you work.<p>In your experience, how can you smell the B.S from a mile away?<p>How do you deal with it?<p>Thank you
======
JoshTriplett
Never believe a hiring manager who tells you they'll hire you at level X-1 and
promote you to level X after some amount of time. Make sure you get hired at
the level you deserve.

Never believe that money is the only thing you can negotiate at a company.
Most benefits are negotiable; the only question is who is authorized to
negotiate them. Vacation policies are often negotiable, if that's a thing you
value.

"Don't talk about salary" (or other compensation) is a common unwritten
policy. Note that it carefully isn't written down anywhere, it's just an
unwritten expectation. That's because 1) it's illegal in many jurisdictions to
prohibit discussing salary/compensation, and 2) it's often to the employees'
_benefit_ to discuss salary/compensation with each other, just not to the
employer's benefit. (That doesn't mean you bring it up in unrelated
conversations; it means it's completely reasonable to discuss and compare
compensation when you're trying to figure out things like "am I being paid
fairly" or "is this person I'm mentoring/advising being paid fairly".

------
pleasecalllater
_This is what I observed in a couple of companies. The most amazing thing is
that some developers think that all is fine, some even like it._

Set a deadline without asking the developers. Or ask them and ignore their
estimates. Or ask them and ignore that they will know after some initial
checks which will take two days ("nope, we must know the deadline now") - so
it's basically just guessing.

Then the deadline is "set in stone". This means only that it's a good way to
punish the developers. Then they are forced to work during weekends.

At the end they are punished with bad yearly reviews, decreased bonuses etc.
Sometimes some are even fired.

Then the management just moves the deadline to another, equally stupid, term.
Of course they will get the full bonus "you see, the developers are lazy, but
we fired the worst one".

Then the cycle repeats. The most funny thing is when the deadline is for some
internal stuff where the client is fully internal and really doesn't care if
the product will be this month or the next one.

~~~
klancaster
I worked with a non-technical manager (banking background, somehow wormed his
way into managing development) who never asked devs what they thought a task
would take. I finally convinced him that this could not possibly work. I sat
with him the first time he asked a dev how long the current task would take.
The dev said "4 weeks". This guy said "I think it should take 2, so that is
what I am putting in the schedule". Mind you, this guy had never written a
line of code and had NO basis for his "thought" on the task length.

~~~
_def
Haha that's great. "Let's settle with 3! Ha, good deal."

Things like these make me sometimes think that the whole business world is
just a bunch of people lying to each other. Very depressing.

------
hirundo
It's not always a trick; sometimes it's quite sincere. My first boss as a
programmer hired me because he tried to write the app himself and discovered
that there were more efficient uses of his talents. However he did learn some
important lessons that he passed on to me:

1\. instead of giving full word names to variables, it is more efficient to
just name the first one `a`, and the second one `b`, and then on the second
pass through the alphabet `a1`, third pass `a2`, etc. He couldn't understand
why I didn't re-use his old code written with this scheme or why I didn't
adopt it going forward.

2\. It is far more efficient to simply not write the bugs, as opposed to
wasting so much time debugging them.

Thanks for the education Frank, I did learn a lot from you.

~~~
_def
I have a feeling I know why he hired you instead of writing it himself...

Also contributing my part: a boss declining unit tests because they cost
money. In the meantime, he's wondering how crucial bugs appear again and again
and urges us to be more careful. It's always a relieve to leave those places
:)

~~~
cryptica
This mindset of "you don't need tests, just don't write bugs" sounds extremely
naive and amateurish at first but having worked at many different kinds of
large and small tech companies around the world for over a decade, I now think
that there is actually real wisdom behind that mindset and I've met some very
talented engineers who share that thinking to various extents.

Debugging trains you to think about code. I think most of my programming skill
comes from my open source project work where I didn't write tests initially.
Now I can simulate code in my mind without having a computer in front of me.
This is a really useful skill - You need to be under some kind of mental
stress to learn this kind of skill.

When you don't have tests to rely on, your mind is forced to hold on to more
details about different interralated parts of the code and over time, this
mental stress trains you to hold a massive amount of detail in your mind and
this helps you to write much better code. Also, being forced to hold a lot of
code in your mind gives you a strong incentive to design clean simple
architectures.

Writing bug-free code is not difficult for me now. Even on very complex
distributed projects. I do write tests for my open source projects now but I
do it at the end after everything is working. The purpose of tests for me now
is just to lock down the code to prevent regressions. For some complex
projects, I do TDD but I focus more on high level integration tests.

~~~
_def
If you are out of the loop because you didn't work on a project for half a
year or even are completely new to a project, this approach seems pretty
impossible for myself. At least with the dynamics I had at the job described
above (which included lots of project rotation among devs). I'm sure there are
fitting settings where this approach might work, though.

------
notacoward
"We believe in work/life balance" ...or the closely related... "We reward
quality, not just last minute heroics.

Yeah, right. I'm at employer #12 right now (30+ years in the business) and
this has never been true. I've been at startups and big companies, I've built
products and services, I've been on the good side and the bad side of this,
but it has never been true. Cases where people are rewarded for doing the
right thing and _avoiding_ crises are rare. Far more often the rewards go to
the people who grind out tons of feature code regardless of quality, and/or to
those who pull all-nighters to debug those avoidable problems after they've
already bitten a user.

If you're the kind of developer who wants to do The Right Thing, and you want
to be rewarded for it, find a company and/or manager who has demonstrably
_done_ that. Do as much of it as you can, but don't rely on it to drive
raises/promotions. Make sure you also do enough of the "move fast" BS so that
you don't get written off before people even think to look at quality or team
contributions to decide between you and the person in the next cube.

------
superhuzza
I worked at a startup that would only hire SWEs who did a 3 month internship
first. The startup would not disclose the post internship salary.

Of course, the post internship salary offers were significantly below market
rates. Many would accept the offers anyways because they had invested time and
energy into the company.

The lesson is to never enter into a contract without full knowledge of it's
consequences and how it will play out.

------
mortivore
If you can just work overtime, and hit this deadline, then things will let up,
and we won't do this ever again. :D

~~~
kbrannigan
This right here. I remember one night, after 9 hours at work, I was gonna log
back in to make some additional commits.

I even cancelled a night out with some friends, because "I really have to make
this deadline"

Then it hit me, if as a competent developer I can't hit the deadline, it's
because management added some extra work on top of our usual capacity, hoping
we'll do whatever it takes to make it.

There's always more work to do. If they don't like me, they can fire me.

Nobody on their death bed said: I wish I spent more time at the office.

~~~
amflare
> There's always more work to do. If they don't like me, they can fire me.

I was at a job were I figured this out. Management was a mess, scope was so
fluid to be essentially non-existent, and it was always the devs fault. So I
said "screw it", I work 40 hours and collect a pay check, and that will be the
extent of this relationship.

Sure enough, about 8 months later I am let go out of the blue for "lack of
productivity" and "failing to be a team player". The example cited? When we
were asked to stay after hours to help the company move offices.

Unless its your company, the relationship should always be about the money. I
am giving a skill for X amount of time. In return I an receiving $Y. Anything
more or anything less either needs to be put in writing, or is effectively an
unnecessary gift. Perhaps it may be one you want to give, but ultimately
unnecessary. And anytime the company asks for more X without giving more Y,
they are taking advantage of you.

~~~
sumo89
Startups are typically awful for this because the business is the founder's
baby and they can't understand why other people aren't willing to sacrifice as
much as they are. I've felt it first hand and in the exit interview the
founder didn't even understand I wasn't in it for the stock options are
they're vested after 3 years and no way he paid me enough to actually buy in.

------
ericbrow
It took me a few rounds to detect this trick. I had a boss who would pick up
on clues from upper management on where they may be headed. He would come back
to our team, and throw everyone at a problem. "This is a priority for
management.", he'd tell us. We'd solve the problem. About half the time, the
solution would die right there, because management never requested it.

What he was actually doing was trying to guess what upper management wanted
before they requested it. This way, when the request did come through, he'd
have the solution on the spot. It made him look great. It wasted about half
our team's time. One thing it did do for us is give us more experience in
solving new problems, but at the expense of getting our day-to-day work done
on time.

But I did get to the point of not being so eager to jump on his "call to
action" meetings unless I had outside verification that it was an actual call
to action by management.

He ended up being the head guy in charge of IT.

~~~
ISL
It has taken me a long time to realize that at least half of the prose I
write, when writing a scientific paper, will be thrown away. Trouble is, until
the full document takes shape, I never know which half.

If someone can predict and deliver what a customer wants, before they want it,
with a 50% hit rate, that is excellent.

What appears to be troublesome in the narrative is, "It made him look great."
It would be far more encouraging to see, "It made our team look great!" I get
the sense that perhaps this boss wasn't sharing success, both credit and
reward, with the team.

~~~
codeisawesome
Haha exactly, most of that comment looked like a glowing praise of that
manager honestly! A rising tide should lift all boats - would be nice if GP
posted whether the team also got any credits and rewards for being the LITERAL
definition of Innovative Risk Takers!

------
asveikau
Management's idea of who "top performers" are tends to get skewed towards
sycophantic or dishonest people, vs. the type that quietly gets the work done
and doesn't care much about credit. But multiple times I have heard
assurances, not to worry, they know who is really getting things done, and
they know who is BSing them. When they say this, they never do.

------
inerte
I like Patrick Lencioni's definition of politics on The Five Dysfunctions of a
Team:

> Politics is when people choose their words and actions based on how they
> want others to react rather than based on what they really think.

To know what others think and desire requires empathy. To counter B.S you have
to do 2 things. Get to know yourself to create a carapace based on values that
protects you, and get to know others, so you know the true reason why they
want something from you. When these don't match (or don't match the proclaimed
company values), this is the definition of B.S

If your values, their values and the company values match, then we can hardly
call it B.S - and don't forget changing values and raising from naiveté is
part of growth. It's ok to feel today you "gotta give 110%" then later realize
this doesn't align with your life moment.

------
malvosenior
Anything related to the "culture" of the workplace. The higher ups are raking
in tons of money. That's it. That's why they are doing what they do. "Culture"
is to keep the workers entertained while the execs scoop up all the cash.

~~~
maxehmookau
nah, I don't buy this.

In a large company, most people _aren't_ making the big bucks and don't do it
to make a fortune. They do it to make a living.

The "culture" of a place, especially at a bootstrapped startup where the
higher ups _aren't_ raking in the big bucks is a huge draw to someone _where
money is not the main reason for taking a job_.

For me, I'm paid well (probably 60th percentile for my location/position) but
the flexibility I get from my employer which cultivates a nice culture and
work-life balance is worth the cut in pay.

That said, if by culture you mean ping-pong tables, free beer and massages.
I'm right with you.

~~~
malvosenior
In a startup the founders may not currently be making a lot of money but they
have a ton of equity that they hope _will_ be worth a lot.

In a large organization the people at the top are making an enormous amount of
money.

My experience is that “culture” is for the people who won’t be getting rich
from the company at some point.

I should add I don’t consider flexible work hours “culture”, that’s a real,
concrete benefit. I’m talking about the organized fun and structured loyalty
attempts management puts in place.

~~~
maxehmookau
Then yeah, I think I agree. :)

------
ravenstine
Scrum, which is "Agile" repackaged in a way that's in favor of management at
the expense of engineers and the work they're doing and, ultimately, the
stakeholders.

~~~
iimblack
Have you met your new overlord, SAFe?

~~~
burntoutfire
We have SAFe at our place for about a year now. I'd say there's a fair chance
it will take over large enterprises fairly quickly. It's so process and
management heavy that the people in charge will love it, and at the same time
it claims to be agile so it's easier to push it down the throats of devs.

------
Apreche
Here, have some equity instead of cash. When the company succeeds, you'll be
rich!

~~~
ravenstine
That or "we can't pay you now but we well... _eventually_."

Came across a ton of those when first starting out.

Like, dude, am I supposed to live on the streets of San Francisco or Los
Angeles just to work for some no-name startup? lol

~~~
dragonwriter
That's not just BS, it's straight up illegal in most jurisdictions (certainly
California) if you'd be an employee rather than a contractor, as worker
protections tend to include not only minimum pay but also timely pay
requirements.

------
whalesalad
Being a programmer is first being a human and second being one who writes
code. Everything is politics. Everything is marketing and influence and
leverage. The quicker you realize this and build these strengths, the more
successful you’ll be at engineering and all other endeavors in life.

Programmers are often surprised by this. “But I just want to write code” –
that’s just a very tiny piece of the puzzle.

------
andyjohnson0
1\. Refusal to accept that task estimates are subject to change.

2\. Managing people purely for their outputs; not as individuals with lives,
career goals, interests, strengths, weaknesses.

3\. Insisting on process but not participating. E.g. scrums with no management
present.

~~~
ravenstine
It depends on how you define management.

PMs should probably be present during sprint planning for Scrum, but any level
of management above PM really shouldn't be there.

I worked at this one place where, as much as I dislike Scrum, we had a pretty
good pace going without upper management ever getting involved. Then the
manager of our department(not an engineering manager) decided to show up to
all our meetings because, shit, why not, and it completely cramped our style.
They also began to dictate that we do things in a specific way even though our
productivity was fine before. Fortunately, like most non-engineers, they lost
interest after a month and almost never showed up again.

Granted, I have found at most of my jobs that management is absent when it
usually counts. At one place we had a "demo day" as part of our Scrum process,
but relevant parties in management almost never showed up. They would even
claim they would show up but always came up with an excuse at the last minute.
It wrecked everyone's confidence in them because a manager can't claim to say
things like "product is key" and then fail to show up to product demos every
single time. Yet demo was something our management wanted us to have.

~~~
Ididntdothis
Your last paragraph is important. At a minimum management needs to understand
scrum and play their part.

------
GlenTheMachine
\- Hold a review for the customer. Insist that the story be simple and
completely positive, to the point of lying. Terminate with extreme prejudice
all references to "challenges", "complexity", or "risk" on the review slides.

\- Convince the engineers presenting the slides that you actually understand
the challenges and complexities of the job. Make handshake agreements that
none of this will be forgotten internally. Say "We just need a simple story to
get through the review hoop."

\- Six months later, forget that any handshake agreement took place or indeed
that anyone objected to the simple, straightforward, fallacious story
presented in the review. The slides, after all, are the only thing written
down. Insist that the engineers never conveyed any challenges to you. Blame
them for delays, overruns, and missing features.

My lesson learned: never, ever sign your name to a fictional budget, schedule,
or risk summary.

------
tempguy9999
I've rarely had any of that. Mainly I get pervasive bad management from poor
but well-meaning managers.

Only thing I can think of is a long time ago being told if you hit this
deadline here's £X thousand pound bonus for the team. We hit the deadline,
they made me redundant next day and told me I wouldn't be getting my share
because "you should have got it in writing"[0]

I took them to court and won eventually. Good fun.

[0] Which was a) true but b) plain nasty. Worth repeating at this point, the 3
laws of contracting:

1\. Get it in writing

2\. Get it in writing

3\. Get it in writing

~~~
crimsonalucard
Wow what was the asshole company that did this?

~~~
tempguy9999
Long dead, don't worry you're safe!

Edit: useful lesson though.

------
nailer
General employment tricks:

\- Asking you your current pay. Not answering when you ask them their budget.
A good answer is to discuss the other offers you have on the table.

\- Getting private info by asking you to correct something false. "So you made
80,000" will get an answer better than "How much were you paid?"

\- Repeatedly asking you the same question because they don't trust you and
have read they'll "get the real answer" if they ask three times.

------
ping_pong
This is the wrong question.

If you feel like management and politics are making you not trust the company,
you should find another job, especially in this environment with plentiful
jobs. If we suffer some sort of recession in the next couple of years, we need
to hunker down in a good company that takes care of their employees.

------
sys_64738
"I worked hard to get you this token raise."

"Work hard and the promotion come. Eventually."

"You'll be a paper millionaire at IPO time."

"This bug needs to be fixed before you go home."

------
hobojones
Any time management uses the phrase 'other duties and responsibilities,' and
anytime management is suddenly willing to implement an idea they previously
fought against.

A few days after switching roles and organizations within the company from
regular system admin work to my first real development job, my old boss
realized they were completely unprepared to continue without me. Due to the
overall importance of my former customer to the company as a whole I was horse
traded among senior management back to my old organization and role on a part
time basis under the 'other duties and responsibilities' clause of my
employment contract.

Prior to switching roles I made the case that the company should back-fill my
position due to overall workload, the likelihood for burnout among my old
teammates, impact to customer, etc (the original intention was to drop the
role via attrition). I knew that something was up when my old manager was all
excited to tell me that the company took my suggestions seriously.

As for how I dealt with it - unfortunately I bent over and took it. I have a
myriad of reasons as to why, but the most salient is I feel I need the
development experience and don't think I'd be able to find job elsewhere just
yet. This has definitely accelerated my overall plans to leave the company
entirely, but in the meantime I'm trying to milk all the experience I can from
my new role and am preparing to quit at the earliest possible moment.

The silver lining out of this is that my partner, family, and friends have all
been incredibly supportive. Additionally the team lead on my new team
understands the situation I'm in and is trying very hard to present me
opportunities to grow and expand my skill set even though I intend to leave
the company in the future.

~~~
loopz
If you were your manager, making your case. What would you say: Would you, in
writing, enquire to know at what date you might expect to be relieved of your
former duties? Who is provided for knowledge transfer?

Point is, having another role and being in the same company, you may
reasonably expect some "support" for your old role. If you take this as
failure of management, you _can_ make demands from strength (of course in a
diplomatic and understanding way).

At any time, dev work may make you miss deadlines, and where's that
replacement?

------
kstrauser
"We don't have a training budget right now, for you anyway, but that will
change next year."

~~~
brodouevencode
Similar to "get certified and we'll see about getting you a raise".

Gets certified, no raise.

------
tommilukkarinen
I dont consider anything bs unless its about money or equivalent. I Dont say
anything at first or something like 'I think about it'. Think about My
response, and finally Ask on something around these lines: "So your suggestion
is X? And it would, unfairly, cause me Y?"

------
Balgair
You need to understand the underlying dynamics of the modern corporation.

Each one is structured differently, but they have general similarities. It
takes some time and study, though. One of the best lenses I have found to view
the corporation is 'The Gervais Principle'[0], now about 10 years young. Rao
uses 'The Office' to illustrate the dynamics of the modern corporation.

Broadly speaking: Sociopaths, in their own best interests, knowingly promote
over-performing Losers into Clueless middle-management, groom under-performing
Losers into Sociopaths, and leave the average bare-minimum-effort Losers to
fend for themselves.

One of the key lenses is the idea of 'talk' and how people in a corporation
talk to each other. Specifically, the 'power talk' of how the sociopaths talk
with each other, and 'the 'posture talk' of the clueless to the losers.

Your question is about 'posture talk', how to deal with it, and how to 'baby
talk' to your Clueless managers. The answer is to pull a Ryan and turn into
one of the Sociopaths, not one of the Clueless.

Though it is only one lens, and one that is ~10 years old now, the 'Gervais
Principle' is a valuable resource and mental model for viewing the modern
corporation and may help you in understanding the kinematics that underly what
is going on with your managers.

[0] [https://www.ribbonfarm.com/the-gervais-
principle/](https://www.ribbonfarm.com/the-gervais-principle/)

~~~
loopz
Research "gaslighting", especially the advice and emotional support articles
about the theme from people with experience.

This is the Old Men's Club, currently undergoing demolishment.

------
ravenstine
Unilaterally setting unreasonable deadlines in order get engineers to "work
harder".

------
agentultra
Two questions I always ask a team: Do programmers on the team interact with
users of their software directly and what are the technical chops of the
leadership in charge of engineering.

Technical chops: do they engage in the wider software engineering community,
what projects have they worked on, do they publish papers, give presentations,
do they have a body of work, etc.

If the answer to the first is no and the answer to the second is difficult to
find out then I don't even need to work with the team for a while to know
there is going to be dysfunction. It tells me that this is an ego-driven team,
inexperienced and politics will play a huge part in getting work done.

If the answer to the first is yes and the answer to the second is still
difficult to find there's going to be _some_ bullshit. You will have a toehold
to fight against it because you can get the data you need from your users.

The answer can be no on the first one and the leadership can come from a good
history of delivering good work. There is a range of bullshit here. You can
still have ego driven development with a lot of bullshit. If you can't talk to
your customers it's hard to know whether your leadership is bullshitting or
not. However if you have done your research on leadership and trust them then
there can be minimal amounts of bullshit.

If the answer to the first is yes and the leadership has a strong background
and is well known then go work on that team. This is going to be a great team
with almost zero bullshit. This combination is extremely rare but wonderful
when you encounter it.

How I deal with bullshit -- get a therapist if you can afford it, group
sessions if you're strapped, or start a group with local people to vent and
get support. Burnout happens when you can't escape an environment that puts a
lot of stress on you and you feel like you cannot control it. You might need
to deal with the bullshit because you need the job to support people who
depend on you. You can't deal with burnout by believing in yourself. Get a
support system.

Bullshit is everywhere. It's often not because you are smarter than everyone
else and can see it. It is often because you can't see everything going on and
nobody can read your mind either. Bullshit happens when well-meaning people
with insecurities are trying to meet unrealistic expectations (whether self-
inflicted or social doesn't seem to matter). The best way to not spread
bullshit is to leave your ego at the door. Seek teams that minimize bullshit
and don't put unrealistic expectations on people.

------
_def
\- working on project A \- jumping into unplanned tasks because of an
emergency in project B \- PM whose managing both gets mad at you because
project A is gonna delay

Making me feel guilty because I save our ass? Time to update my resume

------
oneepic
Manager: When can you have this task done?

Employee: I'll shoot for <day>.

Mgr: Why can't we do <day-2>?

This was common in my team meetings at my last company. The boss was an
asshole in general. He would always reframe things to put tons of pressure on
you to get things done in unreasonable timelines, but he insisted this was
normal and the onus is now on you to explain why we can't get this done in a
"normal" timeframe. In front of the rest of the team.

Needless to say, if you're shy (or too nice), you'll buckle and try to get it
done, and work yourself too hard.

------
homeless_engi
I've been ploy several times to the "Mr. Jorkins" effect: when you have
several managers, an unpopular decision will be the brainchild of the manager
you are not speak to at the time.

------
nickthemagicman
Anytime they say something like "Just do X now and we'll do Y in the future"
where X is an idea you disagree with that will be a problem in the future, and
Y is your proposed alternative to fix things now before they get out of hand.

Get ready to be fixing shit.

------
michelinman
Boss asks 'When?', I say 'You can have it now or in 3 days when it works'.
Boss decides NOW to hit his deadline. Not allowed to book any more time to it.
Slagged of un-mercifully in testing. Thanks Boss. £50Bn business is run this
way.

------
alliao
"I myself personally can't stand politics get in the way of work!" rather
suggestive that they're thinking about it...a lot.

"why don't you be the team leader, but let's not tell anyone..."

Hmmm

------
thewhitetulip
1\. You need to reskill! Future is about x y or z technology

2\. You have already learnt x technology? We can move you of your current
project manger can release you.

3\. _Sighs_ reskilling isn't working as per our expectation

------
Ididntdothis
In my company they sometimes change “estimates” to “commitments”.

~~~
oneepic
How often is sometimes? Always?

------
cntlzw
flattering

