[devjab]

I disagree with this take. It’s software engineerings job to figure out, how, to do it, not if it should be done. 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 and consequences of each option and then let you decide.

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.

[jamil7]

If you’re leading an engineering team in a product company you should absolutely be asking why and trying to find the actual problem that’s often buried amongst solutions that are brought to you from the customer or product or sales. This is how you deliver faster, cheaper and simpler solutions.

[devjab]

What often happens, however, is that when a customer asks for a new bathroom. Engineering will point out that they won’t need it in a year because the customers children at moving out age. Not considering that both the customer and product is well aware of this and their motivation is completely different.

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.

[jamil7]

I think in the scenario you’re presenting the engineering team has failed to surface the problem or the other teams have failed to accurately present it. I do agree with what you’re saying about engineering teams becoming bottlenecks if their immediate instinct is to derail or mistrust other teams and once the cycle has started it’s hard for the teams involved to break out of this pattern. I do still think there is a responsibility for engineering teams, especially at small companies to look for opportunities to solve problems in a simpler or cheaper way if they can and that might not be obvious to other teams. The customer might have actually just needed a sink or second toilet for example.

[devjab]

This is where the less than premium options come into play isn’t it? You can present product with a plan of what they want, and the consequences and cost. You should also present them with other options, which could be an extra toilet or sink. Then you let product and the customer decide if they actually want the full thing or not.

[scott_w]

Disagree. This position completely disregards our experience and expertise. We need to partner with our Product counterparts to figure out what our customers’ needs are. We must also be clear what our operating constraints are so PMs can make an informed decision on what to prioritise based on a reasonable idea of the costs/benefits.

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?

[devjab]

What makes you think you know more about customer needs than the people working directly with the customers?

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.

[scott_w]

> What makes you think you know more about customer needs than the people working directly with the customers?

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.

[nitwit005]

Plumbers will absolutely refuse work. You can just go to /r/plumbing and see discussions of it.

People in just about every profession get asked to do things that are illegal, unethical, unsafe, or impossible.

[devjab]

Plumbers do have the advantage of being third parties though.

As a side note, I have no idea what you mean by /r/plumbing. Is that something that I should know?

[skydhash]

The “plumbing” community on reddit. That’s the naming scheme reddit uses.

[pnut]

That's how Reddit is organised.

[FridgeSeal]

Your comment has big “you’re just ticket monkeys” energy.

> 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.

[devjab]

This is not what I said at all. I completely agree with the article on how you should present options to product and the customer, and then let them decide. In your example product and the customer comes with the solution on how to build it and what budget is needed to you. If you’re staying out of product and customer, then they should stay out of engineering.

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.)

[bilekas]

> It’s software engineerings job to figure out, how, to do it, not if it should be done.

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.

[genezeta]

> A plumber isn’t going to refuse adding another bathroom to your house

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.