Ask HN: What are some B.S. tricks management pulls on naive developers?
As a company gets older it seems like politics are inevitable, no matter how hard or well you work.
In your experience, how can you smell the B.S from a mile away?
How do you deal with it?
Thank you
80 comments
[ 3.1 ms ] story [ 169 ms ] threadI 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.
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.
Gets certified, no raise.
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.
Things like these make me sometimes think that the whole business world is just a bunch of people lying to each other. Very depressing.
A slightly different scenario I see all the time, even today, is when a company takes on a fixed-cost job to build something. We come up with a basic MVP feature set, run it through the standard MoSCoW process, and then estimate how long each feature will take.
We end up with a final figure, and it's over budget. We strip things out, and it's still over budget. Rather than cut out features the client wants, estimates are cut down to fit the budget, or planning time is stripped out and we're expected to go straight into a build.
Funny enough, these projects always run over, and we always end up missing a ton of stuff the client wanted, because in the process of being lean we forgot to do any kind of documentation of changes, or to explicitly get in writing what the feature is supposed to do.
So you play safe and give them a super rough estimates and a lot of buffer.
And now all of sudden you are invited to meeting to explain your super rough estimates. You remind them that it is just a super rough estimate. They ignore that.
Now if you are weak, they will get you to cut your estimate. If you are strong they will ignore your rough estimate.
So they create a deadline based on your estimate. You remind them that it is just a rough estimate and deadline seems unfair. They tell you just do your best, deadline is not a super strict deadline.
Of course, project scope is bigger and there is scope creep. You are unlikely to make deadline.
All of sudden you are being asked why is project going to miss deadline. They tell you you did estimation, you need to meet this deadline. Work extra hours.
You try to remind them that you were asked for a super rough estimate but you are ignored.
Also your teammates hate you because they think you promised the deadline and now they have to work over weekend to cleanup your mess.
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
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
Edit: useful lesson though.
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.
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.
The challenge for new employees is to get a picture of the parts of culture they aren't advertising. The way the company evaluates employees, pursues transparency, treats people fairly, respects boundaries, Cares about customers, cares about quality, communicates internally, etc. are the parts of culture that matter, but they're hard to determine from the website
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.
"why don't you be the team leader, but let's not tell anyone..."
Hmmm
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.
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.
That’s pretty common. Retrospectives are also only for devs, not for management.
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.
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.
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 :)
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.
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
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".
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.
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.
- 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.
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.
> 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.
Making me feel guilty because I save our ass? Time to update my resume