Nobody wants to hear "no". The way you say "no" without saying it is by turning "no" into an option, and attaching costs to options.

"no, I won't be able to make it in time" would be "I can confidently deliver in time if I have X, and we save Y and Z for later."

One trick I learned: If you have the type of manager who doesn't like "No", then say "Yes", but continually keep him in the loop as the project progresses to failure.

If you're up front honest, they'll think you're being lazy - even if you have good reasons.

If you say "Yes", and then fail for all those reasons while providing regular reports, the manager views you as "Someone who is willing to do things".

They often don't care about your actual success/failure rate, but instead use your attitude as a proxy for the actual success/failure rate.

Also, as the project is moving to failure, he'll usually intercept with "OK, how about we changed the requirements to ...?"

If you asked for that change in the beginning, the same rationale as the above applies.

Internally, it’s important to understand that every ask should have a business goal associated with it. The thing being asked for is rarely (never?) the only way to accomplish that goal.

Great engineers focus on the customer or business need and find/propose alternatives that are possible.

> and I think it is somewhat similar to say that you have to "lie a bit on your CV". [...] For context, I'm early in my career (3 YOE)

Please consider this input from my YOE battle scars:

1. Don't contradict your team while in a meeting with outsiders, but then you're obligated to follow up with your team offline, to try to mitigate any damage, and try to make sure it doesn't keep happening. For one example of why, I've seen one person consciously "mis-promise" things to customer, and when I talked with them offline about we couldn't be saying that, because it wasn't true, their response was "they won't remember". Narrator: "They did remember." And that's possibly why that person and a few others aren't very wealthy today.

2. Not everyone believes in "lie a bit on your CV" nor similar dishonesty. You'll probably meet colleagues, who you respect, who react to that with surprise and disappointment. You could also get fired for it, with cause. Especially if you're calling yourself an engineer, since determining and telling the truth is much of your job.

3. Though, on the other side of CV honesty, be careful about always using team-speak/think when in an interview context. Out of habit, you might naturally say "we" when talking about something you were instrumental in. But some people who think lots of people lie on their CV are going to hear that "we" as you generously including yourself in the accomplishments of others. I've started switching modes a little more for interviews, expressly claiming more credit, such as by saying unambiguously when I was the sole designer and implementer of something.

It took me years to notice that folks who confidently made stuff up or provided incorrect info in meetings were looked upon favorably. No one ever knew or cared that the thing the person said was incorrect. Just the confident way they said it.

Aside: start getting that exposure to management people now. You can book regular skip levels with your bosses boss and the PMs boss. Better than waiting until you get promoted and having to learn how to do it with a weight of expectation.

When everyone in a game is cheating, you will lose by playing fairly. And like other commenters have suggested - everyone expects similar behavior.

> For context, I'm early in my career (3 YOE) and I don't deal with management that much yet (I'm still shielded by my tech lead and PM), so I'm always looking for advice on how to navigate these things. I really can't just say "YES, YES, YES" when I know very well that something won't be possible.

It depends on a lot of things, like how big the company is, how critical the project, culture, management style, etc. - but you'd be surprised at what is actually possible that may sound impossible. I've had those "this is impossible" thoughts a lot early in my career and more often than not I was wrong. The few times I wasn't wrong, I made sure to highlight risks I saw at the outset, and when the risks materialized, point them out at the retrospective or whatever for CYA purposes.

The things you do want to avoid at all costs are death marches, impossible deadlines with consequences at the end of it, maintenance slogs which will tie you to a very annoying treadmill for your entire tenure - it's hard without experience to know where these things lie, but if all else fails, you can do what everyone else does, try the impossible thing, and either surprise yourself, or when it becomes clear it won't happen, toss it to some overly ambitious sucker (I don't condone this, I just have seen it happen far too often).

the corporate world is a lot of kayfabe and bullshit. Welcome. :)