It's always a bit disheartening when I see someone from the engineering, product, or marketing sides of the business not understand the most basic of principles that salespeople learn at the beginning of their careers... people mostly make decisions based on needs, and if you don't ask and understand their needs you won't make the sale. Also, the more painful the problem that drives a need the more likely you will make the sale.

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.

> One of the most valuable life lessons is you can't get anyone else to care about what you want them to care about basically ever.

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.

I am slowly and sadly learning this lesson. My customers are devs, and I want so badly for them to care as deeply as I do about RDBMS optimization, normalization, and referential integrity, but by and large it’s a fool’s errand.

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.

Generally, I've found more success in professional interactions if I approach them not with the intent of convincing the other person of something, but with the intent of learning about their fears, concerns, and desires.

It takes a little longer and gets to my desires only obliquely, but I still tend to like the outcome more.

Indeed. Things I've used before are: "product speed is declining, see this chart. We must make these optimization to stay acceptable." And for example "We must migrate to this hosting model to keep compute costs down."

Thanks for that nugget of advice! I probably already know it deep down inside, but seldom remember it, and seldom act with that mindset. But yeah, so true. Don't try to make someone give a shit about something that they have no reason to give a shit about. Instead, tell them what's in it for them, then negotiate so there's still something in it for you.

This is small-p politics.

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)

One of the few strategies that I've seen works is "I'm going to do it this way, and I'll take all responsibility for it failing." and then if it fails, actually take responsibility for the failure.

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.

This! It's the basis for fruitful negotiations to understand what the other person needs (which is not always what they say at first). Sometimes you can give them something that's cheap for you but valuable for them or vice versa. I can recommend the book "Getting More" by Stuart Diamond for valuable insights on how to do this.

Worth adding that managers have to report upwards. So you not only have to be able to generate sympathy for someone who presumably knows your product & team well, you have to arm your manager to go upwards with a good story about where your team is spending its efforts that even less technical less intimately connected business operators will need to at least check off on.

I agree with this. I want to add a product perspective here too. If your product partner routinely tries to understand your suggestions and translate them into the things that matter to themselves and the broader organization, that's a good partner.

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.

There's also the Bernays approach: sell your design as filling some emotional need and convince the stakeholders that they have that need.

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.

I think of this as empathy. Step into their frame, look around, and then come back.

> Discussing technical changes with non-technical people is usually a giant waste of time. They often don't understand what you want to do in the first place and think it's optional, because why else would you bring it up for discussion?

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.

This is it, right here, but the problem is that in the modern corporate agile model, they want to plan ALL work done through optimizing the backlog with product, and they want ALL of the available hours to go to that work. That causes these teams to have a very difficult time negotiating the right things into their workload, and if you do it by fiat other things necessarily get pushed out.

> Ah, the contract relationship

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.

I can tell from your comment that you are on the engineering side of things. Corporate should focus (among other things) on reducing COGS, product again should focus on delivering customer facing features.

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.

The issue is that most people are not cross-functional thinkers. Those who are not generally fall prey to the “if you have a hammer, every problem is a nail” fallacy. Engineers want to engineer, PMs want to add features, managers want to “manage”, etc.

I had the same feeling when I read this. This engineer needs a product person pushing them to rethink their architectures, and shows that it's helpful to have technically minded Product Managers that can call BS on engineering when warranted.

Yeah, the whole article seemed “webscale for webscale’s sake”, despite describing a product just a few steps beyond MVP.

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.

[dead]

In a "perfect" scenario the product would not require any more development and thus development could be reduced to zero.

> This plays into the worst fears of the product manager, that you are engaging in resume driven development that benefits you, your sense of fun, and your personal growth, over what is best for the product and the company

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.

I think I did realize that. However, if you as a homeowner say "I really super duper don't want any scale buildup OR the minerals to be dissolved in whatever comes out the faucet" then suddenly the proposal is actually reasonable.

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.

IF you are building software to build a product, and the company has put you on the product team in their organizational structure, you are on the product team, if they haven't you and they have a problem.

Works great until someone’s asleep at the wheel and chooses option C! (Speaking for experience watching exactly that happen to someone else… repeatedly.)

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.

Slightly related: Water pressure regulators have a typical life-span of 10-15 years. Found that out when a co-worker did battle with some low water pressure.

Very curious to learn about what classes one can take to build up a rudimentary knowledge of plumbing, electrical and HVAC.

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.

Then you have a mediocre developer not willing to align his interests with those of the company. Cannot end well.

Ok but what does this have to do with the topic?