So if you want something done and someone else has to agree, you have to figure out how the thing you want coincides somehow with their interests and concerns.
Then you explain the thing you want to them in terms of how it advances/affects the interests and concerns of the other person. So in the framing of TFA, product are never ever ever under any circumstances going to give a shit about your architecture proposal (because that is entirely in the domain of your concerns). But they may care about how the architecture is going to prevent them from delivering features that are on the roadmap coming up and how you have a solution that can fix that for example (because now you are in the domain of their concerns). Notice this is not just "your architecture proposal", it is how your architecture proposal is going to get them what they want, and if you want to do this you need to think deeply and make sure you really understand what they want, not just what you want.
You're not trying to change their mind. You're trying to get what you want by showing them how it will also get them something they want.
I'm putting this here because I really wish someone had told me this 25 years ago near the start of my career.
I had the benefit of learning this before I ever went to University by working sales jobs while in High School, and boy has it made my life easier not only as a programmer but also in nearly any collaboration with co-workers.
Don't recite features and benefits, that's just lazily hoping the person you're trying to convince will do your job for you. Take the time to ask enough questions to know and understand their needs. If the thing you're pitching can at least fit, and preferably help solve, some of those needs then you have a good chance of getting them to buy in. If, on the other hand, it doesn't address a need they have then you're going to struggle to convince them... and perhaps that may also be a clue that your solution may not actually be the best way to go.
The idea that one can ask me a few questions and give good advice when buying a phone, a car, a house etc.. is just bizarre.
Maybe it is not like that in the general population, but it certainly is within technically-minded people.
A good salesperson will make sure the choice process is relatively quick and painless. You will feel good afterwards knowing that all the 125 aspects that differentiate this model from the other ones are not that important. The one you chose runs your favourite apps, integrates well with your car and your home entertainment system.
Understanding this and learning how to sell helps in life, incl. negotiating architectural changes with non technical decision makers.
The best salesperson isn't the one whose customers are leaving the shop smiling just like a TV advert where buying X or Y will solve every problem in life, but rather the one whose customers leave the shop angry after having purchased this or that product or service, because that is an indicator they were squeezed until just before the point they tell the seller to stick their product somewhere and leave for the competition. Not that I like it, but that is how I see it.
Low trust == maximize mechanical power and optimization
Higher trust == invest time, relationship-building and lower individual transaction profit over a larger volume of profit
Few consumer sales interactions fall into the second category.
I know what I need just gimme the 100 MBPs plan!
Exactly except:
If you're a CEO, the info you care about is one set of info.
If you're a user, the info you care about is different.
If you're some other influencer, the info you care about is different again.
Everyone wants different sets of info. Good sales is figuring out what that is and giving it to you.
They also want to be able to pressure you for "next steps" or the "follow up" meeting.
I get it, a call can be a lot more efficient for a discussion. There are certainly legitimate reasons to prefer a call to an email. But it reminds me a lot of big tech companies seizing to things like "security" as an ~excuse~ justification for doing things that benefit them. I know the motives aren't pure, and that bothers me.
They would come from the manufacturer manual or a spec sheet or something like that.
Windows has some objective, known, minimum hardware requirements. Are they open to interpretation?
What kind of products are you buying that make you wonder how to get objective facts about them?
I don't think that it makes any sense to choose OS by minimum requirements.
Unless you're a 1 person company, nothing you do ever only impacts you.
Usually people say that people skills are as important for having lots of impact as technical skills, but the bar for people skills is really low sometimes I guess.
They are simply saying that any system involving multiple people will also involve people convincing other people to do things.
Do you have a system which doesn't involve that? Does it involve cybernetic implants and hive minds?
And, just to echo this, it is quite common to see people go down in flames because of issues they knew about, were told about repeatedly and simply didn't (couldn't?) take an interest in. A situation being important isn't normally enough to get people to change their methods. They generally just do what they always do come hell or high water.
A lot of people seem to struggle with this and put it down to stupidity - which is correct, but it is more useful to see that one of the mechanisms is people not being able to do things differently based on how urgent circumstances outside their immediate concerns are.
What has worked to some extent is patiently walking them down the path of what happens if those things don’t happen, e.g. “so no one uses lookup tables or enums, so now every row has X unnecessary bytes, which puts pressure on the buffer pool, and then everyone’s queries slow down, and everyone’s SLOs trend down…”
It doesn’t always work; I’ve also had people respond that “they’ll fix it later,” (lolol sure) but it’s had better results than simply explaining why their schema is technically sub-optimal.
The absolute worst to deal with have been those who seem to completely lack empathy, and respond flatly with, “fixing that isn’t on our roadmap, and isn’t likely to be,” even when I explain that in X months, my team will be suffering from their decisions.
But giving them the query, or writing the migration for them, often takes care of both one and two. I've even seen this approach ignite a passion for query optimization as it "clicked" for them!
What I’d love is for devs to treat SQL the same as they would their primary language, instead of some mysterious and arcane artifact to be abstracted away and ignored. If I refused to use any data structure other than a dict / hashmap because “it’s good enough,” how do you think that would go over?
Of all the optimizations I have meassured (and I have meassured a fair number), only two types have really moved the needle: do less, and use a better algorithm.
If we need to shave a few percentage of the database access, it is more cost effective for us to get a more powerful database server. Assuming that we already have a cache and aren't doing something stupid like not using an index.
At toy scale (if your entire dataset can easily fit into memory on a small instance; probably < 100,000,000 rows total), then some things don’t matter as much. I disagree that they aren’t meaningful, though. Especially with Aurora, and its “what if we added even more latency to queries” model of splitting compute and storage. Go make a table with a few million rows; one column with a sequential ID, the other with UUIDv4. Index them both (in MySQL, you’d need to swap PKs between tests since it clusters), then do any kind of aggregation query, like COUNT, MAX, etc. That’s not a small difference.
A micro-optimization for an RDBMS would be something like switching a MySQL column from VARCHAR to CHAR if you’re positive that the length is fixed, to save the 1-2 bytes/row overhead. It matters at scale (thousands of tables * millions of rows can add up), but not for most.
> If we need to shave a few percentage of the database access, it is more cost effective for us to get a more powerful database server.
People always say this as though it’s fact, but I’ve yet to see any studies on it, and frankly I doubt its veracity. Take the current RDS pricing for on-demand Postgres, r7g.large vs. r7g.xlarge: in us-east-1, it’s $0.239/hr vs. $0.478/hr. That difference works out to about $2000/yr, for a single-AZ DB of the smallest non-burstable type they have. Since microservices remain all the rage, multiply that by N. You’re telling me it’s not worth the money to spend a few hours reading docs and applying the knowledge? I don’t buy it. Moreover, as someone who enjoys the craft of SWE, it’s physically painful to watch people say “eh, let’s just throw money at it” instead of understanding where their code is slow, and solving it.
It takes a little longer and gets to my desires only obliquely, but I still tend to like the outcome more.
How do you measure product speed in a useful manner?
I'd disqualify metrics such as number of tickets, lines of code, and "story points", because they either have an undefined relationship with product velocity (e.g. LOC per week), can vary in size too much to be useful (e.g. number of tickets per week), or they're tautological (e.g. story points per week).
What's left?
In a hierarchical organization, you can give directions to your direct reports. You cannot give directions sideways. You certainly cannot give directions upwards, unless it's for something legally binding like safety.
This means you need to ask nicely, to persuade, invite, and probably compromise. It's a very different set of skills.
(a "non hierarchical" organization has a hierarchy too, but it's more fluid and hard to see)
You have to have a certain confidence in your opinion, and you have to be prepared to destroy yourself mentally and physically to deliver if things go off the rails. But once your deliver something that matches your vision, usually worth it.
And on the subject of things that are good to learn early in your career, everyone should know that every business is barely good enough for what it is. If it was materially better at something else that mattered, for example to its market or its economics, it would be a different business. For profit businesses are pretty effective equilibrium finding entities. I used to get really frustrated that people didn't care about improving things that I wanted to improve, until I realized that in most instances those things wouldn't really change any outcome in the business. In the cases where it would really change the business outcome, I realized the company couldn't prioritize effectively.
Automobiles will make you free! This kind if free software is "free as in beer" and who doesn't want more beer? My queuing system will make you virile and attractive! Whatever works.
Where this deteriorates (imo), is if you're in it for additional reasons other than only the money, but want to build quality things, make the world a better place, yada yada. Or perhaps you like the company and what they do, or something about your job, and actually depend on long term viability. By somewhat strained analogy, imagine the plumber works for a housing co op, and they themselves live there. Suddenly, the plumber becomes a bit more coupled to the choices of "product" or the customers. Poor decisions could devalue the neighborhood and your own resale value, or even damage your own property.
This is why outsourcing usually goes bad
I am from Brazil and I often try to explain people from other countries that if you really want to outsource work you _have_ to build an office in the target country that _really_ works in the same way as the HQ. But that is far more expensive of course.
The people in Brazil who end up in those kind of outsourcing "software factories" are not the ones most Brazilian product companies want.
That points to everyone being focused on their own goals rather than working together to deliver the product that will satisfy customers the best.
The problem are timelines. We all know what technical debt is. You can cut corners and rush a feature out, however at the expense of future velocity. When engineering and product collide, engineering triangle forms and compromise has to be made. The classic triangle is defined as quality -- speed -- cost, however that is more applicable externally. Internally the compromise triangle looks more like "fixing bugs -- delivering features -- maintaining future level of bugs". The more the triangle is stretched towards "delivering features" the more maintenance suffers.
I have seen this coming from engineering far to often. Oh no, product are idiots, they do not understand importance of bug fixing, cleaning of technical debt and maintaining architecture. Believe me, they are roughly as smart as you, you are in the same broad team anyway. Where product fail is at estimation. They lack domain expertise to correctly gauge the impact of rushing a feature on future velocity. They probably understand this relationship, but they cannot quantify the effects. This is where engineering comes: to provide domain expertise.
As TFA correctly implies, product does not give a shit about architectural decisions. For all they care it can be held by either literal or metaphorical duck tape. It's the job of engineering to quantify the cost of rushed features. If engineering thinks that product are idiots for rushing n features, then either 1) engineering fails at understanding business goals or 2) engineering fails to convey impact of rushed features.
Both are communication problems. Interestingly, the onus is on management to sort internal communication out.
My current role is "Director of Product and Technology", so I have to look after both domains. I have deep knowledge in technology, but if I'm not going around the company asking other departments what the impact of the work they want is (and what happens when they don't get it), I'm just plain bad at the product side of my role.
At the other end of the scale there are many programmers who are in the habit of making up bullshit technical reasons why something can't (or shouldn't!) be done when the real reason is they just don't want to have to do it.
Often they'll resist doing a useful feature because it can't be done perfectly. For example we can't report browser tab memory usage because some memory is shared between tabs so the numbers wouldn't make sense. I used to do that until I had a manager that changed my view.
I don't think of that as a problem, that's one of the primary goals of product. Problems (yuuge problems) arise when product also gets to dictate cost/timelines. Sorry, that breaks basic management principles.
> I used to do that until I had a manager that changed my view.
Small, young teams (e.g. startups) can easily do without management, because communication is unhindered and ad-hoc. The more organization expands and matures, the more communication suffers. That's the primary goal of engineering management - facilitate conversations. When I have a request that is tad too technical I always try to backtrack and ask what's the business goal. I am 99% certain "display memory usage per tab" is not the business goal. "Find resource hungry tabs" sounds like a good candidate for a business problem.
"Customers" (e.g. product) tend to be "helpful" and provide technical implementation details, diluting the business problem, while engineering tend to fixate on those implementation hints as if they were technical requirements. Ever noticed how technically inept product managers/owners sometimes tend to be good managers? Well, they are either aware of their technical ineptitude or are inept so much that they can't even express technical details and form their requirements as business questions which leaves implementation details open and allows engineering to implement things "correctly". It's magical how simply communicating on appropriate abstraction level can lead to awesome results as each team can focus on what they are strongest at.
He didn't really say anything to change my mind, he just kept asking for things that would be useful to customers and eventually I realised that even if we can't give an answer that makes perfect sense or doesn't work all the time, we can still do better than nothing. Very often something that is roughly right and can be shown some of the time is better than something that doesn't exist at all.
It kind of sounds obvious when I put it like this, but you'd be surprised how often you see "we can't do this very useful thing because <minor flaw that means it won't always work perfectly>".
Those people that are in the decision-making process need to then communicate the result of the decision with their team, and be able to justify the decision.
Similarly, don't plan refactoring or architecture changes on the same board as your feature requests. Product managers will think they can change the priorities of this type of work and then they will.
The only thing that is useful to discuss in advance is scheduling when you can take the system down for maintenance.
For the rest, it's better to ask for forgiveness than to ask for permission: just do the changes that you think are technically necessary to keep everything running smoothly. Measure the outcomes and present them professionally.
Of course, with maturity as an engineer, I mean that you will not decide to do crazy, hype driven things like rewriting everything in Rust and then not doing any new features for a year. You have to be able to make trade offs and compromises to keep both sides happy.
This bears some—well, all of, the emphasis.
I’d come at it even stronger I think. Asking people in non-technical roles to make technical decisions is a complete abdication of the responsibilities of your role.
You were hired into engineering to take care of the engineering. That is your role. When’s the last time someone in sales showed up and asked you “This guy wants a 25% discount. Do you want me to give it to him?”.
They _may_ show up and say “This guy wants a 25% discount and I’m trying to get a better understanding of our costs. Would we be taking a loss on that? Can you help me understand the costs of delivering service X?”
And that’s exactly how engineers should be approaching this. The technical decision is yours, however you probably don’t have the same context everyone else has. You _should_ discuss your decisions with others and consult with them, but that discussion is best had in terms of the impact the decision will have on their area of responsibility… which is not technical decision making.
In the situations where engineers are going to product to ask whether we should move to microservices or if this UML diagram makes sense, I’ve always seen engineering looking to pass off the decision so they can pass off the responsibility. I’ve run across this in multiple organizations and it was completely dysfunctional every time. And in every case simply replacing the engineering manager with someone that wasn’t afraid of decisions or responsibility quickly resolved the issue. (Which is probably you if you’re in this situation… if there was engineering above you, you’d be asking them instead.)
The discussion to be had should be more along the lines of “FYI, we’re looking to fit in three weeks of additional engineering work this quarter to substantially lower the costs of working on service X going forward.”. Product can discuss their priorities, or even share some information you don’t have yet like “We’ve been discussing axing that service entirely. Our tentative offboarding plan is having everyone off by Q3. Do you think the investment’s worth it?”.
If you continually ask someone else to do your job… well, be careful what you wish for.
It's funny you say that. My career hasn't been as wide and varied as many. My roles have been across wildly different industries, but I only have one person's life to live and my average tenure has been around 5 years. I've had a lot of time to reflect on these sorts of issues in depth, but not to see how they apply across as many situations.
That _exactly_ describes the organizations I had in mind when I was writing that. I have no extra useful insight to add or anything, just that you've definitely given me something to chew on there.
This is the actual solution in the vast majority of circumstances. If after x days you realize you've made a terrible mistake, that's a nice problem to have.
Overengineering abounds. It’s easy to feature flag something and roll it out only to a fraction of the userbase and see if the database falls over, or if you’re biased toward acronym/resume-driven-development.
We’re almost certainly talking about megabytes here, not terabytes.
> You can invest [your spare time] each week towards something bigger like a pub/sub system so that you can pull a new microservice out of your monolith.
I saw someone do exactly that - the problem to solve was simple, but one of the goal of the tech lead was to be able to do a tech talk about the solution, he was just in the company to deliver this project so unsurprisingly it ended up being massively over engineered and a difficult to maintain. To add an attribute in the response of an API you would unironically need to edit 10 files, and this is for a small service.
Metaphors only go so far. Try to see what I'm really saying here: quality has a cost. Don't shoot yourself in the foot by preemptively reducing quality on account of some ill-conceived notion about how the relationship between product owners and engineering works.
This is only true for mediocre companies. Software development is really a force multiplier, not a cost center. A good optimization for a proprietary app saves time for everyone at the company that uses the app, or for your customers if the app is a product. Also important is that the developers can dramatically alter the cost structure both for the current set of features, as well as the future support and additional features. Product faces outward, helping prioritize features for customers. Development faces inward, minimizing tech debt and future work for the company. Both halves are needed to design and build a good product in a reasonable amount of time.
If there’s one right answer, why even present options A or C? If there’s only one realistic option there’s no decision to make. Just go ahead and do the thing.
And if they choose option C we make sure there's a paper trail to cover our asses and then a bit later find a reason to revisit the decision.
I’ve seen this strategy play out and the result is just a deteriorating trust between product and engineering, “we really needed to wait 6 months for this?”
IMO it is a negotiation but the answer to that isn’t “threaten product with huge timelines.” Folks really need to come together and understand which parts of the architecture roadmap *can* be band-aided for now and which can be completed properly within the context of the product’s upcoming needs.
YouTube and a willingness to experiment will take you a really long way. ElectricianU was really good for learning about the electricals. I've been in this house for a decade now, and I pretty much do everything on it including a down to the studs remodel of a bathroom and kitchen, re-running and adding electrical circuits (replacing and pig-tailing aluminum)... I'm on the fence about whether I'd replace the furnace when it's time, it will need a new intake/exhaust run, but otherwise should be fairly straightforward I'd think. I did just pay for a new roof.
Just be patient with it, it will take longer than you'd like and longer than you'd expect, especially if you can only fit in time on weekends to work on projects. I never seem to have much gumption left after work.
YMMV related to pulling permits. Our local building dept is really easy to work with as a DIYer.
Why do you propose to us to be like this?
Excessive craftsmanship and over-engineering may kill your product as much as over-selling features may kill the project.
I had been in such situation and it was nightmare
A good mantra in anything related to any sort of business is that anything can be done, it’s just a matter of cost. Of course it’s on the business to accept that, and if they can’t, well then you can’t deliver what they want. Which is probably what you meant, but it’s only at that point you should say no.
Even if your engineering department is quick to accept that, it’ll be a waste of everyone’s time that engineering chose not to trust their own organisation to be good at their jobs. Leading to a rift between software engineering (and IT in general) and the rest of the organisation. This eventually leads to IT not understanding why departments start buying their software systems from 3rd parties, or why nobody in management will listen to them.
It’s the job of engineering to point out that adding that bathroom will require a massive rebuild to preserve the integrity of the structure of the house. It’s not their job to tell product that product actually doesn’t want what they are asking for.
Doing anything less is basically shitting on Product and, if you have that attitude, why do you think you deserve to be treated as an equal in the conversation?
I think we sort of agree though. I think presenting product with various options and letting them decide includes a lot of what you suggest here. Including working with product. Ultimately though, it’s the job of engineering to deliver what creates business value. Refusing to add a bathroom to a customers house because there are engineering concerns or thinking you are better at spotting customer needs than product is the opposite of that in my opinion. Of course the flip-side or this is that you need an organisation which will accept it when engineering points out that adding a bathroom will be widely expensive because the foundation needs to be reinforced, or maybe the entire house needs to be rebuild. Without that you end up with Boeing.
I do think that thinking you know better is unfortunately one of the pitfalls of our profession because we’re so used to working with patterns, but often engineering won’t even be told the full picture. I find it to often be a humongous waste of time if engineering has to be taught why something is actually necessary before they can get on board with it. This is not me saying that forcing engineers to do something they think is a bad idea is the right way to do things. This is me saying that I prefer engineering departments which are cultivated towards delivering value, and not being obstacles you need to “convince”. This is so often the reason software engineering (and IT) in general is disregarded or seen as “them” in organisations, because they are the people who deliver problems rather than solutions.
I never said I did. What I said was that we should not disregard our own knowledge and experience when working on our products.
We should be expected to get a good enough understanding of our customer/user needs to be able to challenge Product prioritisation and also to make our day-to-day decisions better when building out the product.
> I think presenting product with various options
This wording implies an abdication of responsibility in my opinion. We aren't "presenting options and letting them decide," we're collaborating with our Product counterparts to help them figure out how to prioritise which customer needs we tackle first and how we could address them.
On the flip side, our PM can (and should) understand and challenge our technical considerations. In some of the examples given, maybe we can run a restricted set of reports or not allow certain features, or build a PoC for a smaller user subset just to validate the idea.
That collaboration needs to be built on a foundation of trust and knowledge of each others' strengths. My manager trusts my technical knowledge and my people-management skills but he'll still challenge my decisions where he may have a different context or point of view. Just as I do with my direct reports.
> Refusing to add a bathroom to a customers house because there are engineering concerns or thinking you are better at spotting customer needs than product is the opposite of that in my opinion.
> I do think that thinking you know better is unfortunately one of the pitfalls of our profession
Since I never said any of these things, I don't see any need to address them.
People in just about every profession get asked to do things that are illegal, unethical, unsafe, or impossible.
As a side note, I have no idea what you mean by /r/plumbing. Is that something that I should know?
> A plumber isn’t going to refuse adding another bathroom to your house, they’re going to tell you how it can be done and tell you the cost
Let me know how the plumber reacts when you then tell him said bathroom needs to be freestanding 300m in the air, and the plumbing needs to be made out painted twigs and twine (because your housemate thinks they look pretty), and you also want heated stone floors and you have a budget of $250 and an ice-cream wrapper.
In the miraculous case said plumber accepts the job, make sure to change specs halfway through.
In your case it would be your job to figure out how it could be done, figure out other cheaper options and then present them with clear outlines on what each option would cost. If you get a budget pushed on you from something like sales, then your organisation is dysfunctional similar to what GP was suggesting. (I’m obviously not suggesting that this doesn’t happen.)
This isn't true in the explicit sense you've written it at least. How it should be done is very dependent on if what was specifically asked should be done.
Client says they want automatic payment processing without users approval. Technical capability, absolutely.
Client says they want to disable unsubscribe payments options to retain more subscription revenue.
All can be done from a technical standpoint, but its an engineers job to explain to the client that it can't be done that way.
Many plumbers will definitely refuse doing some things. They will tell you something like "we don't do that sort of work" and tell you to find someone else.
Similarly, a developer might not be interested in quality and customer satisfaction, but in doing the things that will yield him better outcomes: a better position inside the company, better payment.
But isn't the problem with this whole idea that it outlays a possible sale of a "bill of goods" insofar as we don't actually know if a project of this magnitude will actually take the time we say, and require the resourcing it requires?
I'm sorry, but I disagree with the entire premise of this post. Product may have the money but money doesn't do much on its own, and that's more an unfortunate artifact of business-school-oriented modern org charting caked with plenty of management self-importance.
If they want a product, they'll give me the time _and_ the money and go back to dealing with customers and investors. This post is _exactly_ the reason software development today is a shit show of agile and mid-level managers deciding what tech debt is worth addressing. I daresay product can go away entirely, and I would bet the product would still get built.
We have the money and time to build great products. We don't need to sell product on it. We just need to be left alone to do it.
Why should I care if Product cares about my architecture proposal? They are not qualified to judge neither the quality, nor the priority of technical architecture decisions. Those are matters for engineers. Are we doing some "ask the least qualified person to make the decision for you"? Why don't we ask random people from the street, while we are at it?
I might be coming off too harsh, but the whole premise of involving people who are not technical or mildly technical, into making technical decisions, is hilarious to me. Shall I crash the sales' meeting, and tell em how to approach this important client, or expect someone from legal to wait for me to decide that contract is legally sound?
Most of the Product people I work with and have worked with collapse easily under technical arguments, but most engineers I work with barely know what they are doing. Only yesterday I (external consultant) asked the tech lead to scp a file from a to b during a workshop zoom where I showed them how to use some new tools and, while he always talked in front of the cto and head product about ssh and scp and his linux chops, he had no clue; he started to download gui tools (windows) and after he was done he still couldn't. I ended up copying the f'ing file to chat (I have no access to their internal systems). This is the guy they trust with core products dev that runs the company.
He gets away with it because he talks in difficult tech bla to the cto and product (both MBAs); he keeps using terms from kubernetes (they don't use kubernetes and the guy cannot use docker) and 'things he did in the past' at 'much larger companies' and you can see Product go to his happy place during calls. In the end he lets tech do whatever they want as he understands nothing and gets so much tech babble that he cannot even figure out what to ask.
We (small company fixing emergency tech stuff; for this client, it turns out that the emergency is basically their tech department; it's staffed with 100% incompetent people who are decades out of date) hop around a lot and this is very very common; on HN we read about flowers and fairy tales of covering tests, 10x programmers, migrations, kubernetes/containers, git, security etc; in reality however people are sending zip files with dates in them, updating the prod db manually and copy pasting files in whatsapp because they don't understand ssh works (what even IS there to understand ...) and tests? What is that? And these are companies that make more than your startup will ever make statistically.
I am going to say that generally the plumber gets his way in the world, the fear of leaks, water or sewage, is enough for people who know nothing about plumbing (it's all pipes!).
People like to bargin and negotiate, feel the "control". You must start off with an unacceptable price, then talk through "tradeoffs".
If you plan it right you can get the exact "tradeoff" you need.
You absolutely should explain (at a high level) what the constraints of your work are. If the PM doesn’t care, that’s a failing on their part. It’s their job to understand what’s possible within given timeframes and it’s your job as an engineer to explain that.
If a feature requires major architectural work to achieve, then make clear what that is in terms they can understand. “We need to migrate 30m records affecting 20,000 customers to this new system with 0 downtime” is understandable to most people in tech. It can also help focus minds on what we could change to make progress on or just validate a goal before fully committing.
For context, no plumber I know would talk shit about “platinum packages,” they’d just explain what the cause is and what’s making the correct fix so expensive.