How to make Product give a shit about your architecture proposal (opens in new tab)

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.

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.

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

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.

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

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.

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.

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.

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.

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.