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. You need to focus on the things you can control and one of the things you can't control is what someone else is going to care about.<p>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.<p>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 <i>how your architecture proposal is going to get them what they want</i>, 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.<p>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.<p>I'm putting this here because I really wish someone had told me this 25 years ago near the start of my career.
In my experience/opinion, if you are mature enough as an engineer(ing team), you should be able to make and implement most technical decisions on your own.
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?<p>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.<p>The only thing that is useful to discuss in advance is scheduling when you can take the system down for maintenance.<p>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.<p>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.
Ah, the contract relationship. Minimize your output while maximizing your ROI. I think this works fine if you plan on being in the software "service" industry, kind of like the plumber. It helps if job mobility/demand is high so that when the "product" decisions tank the company/product, you just shrug and move on. That's what the plumber would do. In fact, if your customer does the stupid thing, and ends up having to have you come back to pay even more money, hoorah, more money. It's a reverse incentive. Do it enough, and you'll be just like Boeing and the US Government. I've also observed that this type of relationship tends to cause people to optimize short term over mid to long term.<p>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.
Maybe it's the norm, but it's a dysfunctional company if you have engineering that only cares about "doing things the right way", product that only cares about "get the next feature out as soon as possible", and corporate that just thinks "minimize software development costs". And on top of that, you have arbitrary regular deadlines that dictate the flow of work.<p>That points to everyone being focused on their own goals rather than working together to deliver the product that will satisfy customers the best.
> Sure, you could “just” murder your database with table-scanning queries that join every single table and hope that you’ve provisioned a beefy enough machine to handle the load “for now”. Just like your plumber could “just” fix a pipe leaking on the floor by shoving a bucket under it and telling you to empty it every week.<p>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.
> The reality of the world is that product holds the money and software development is seen as a cost center to be minimized towards zero.<p>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.
This person doesn't seem to realize that the plumber was selling them a bunch of shit they didn't really need because it was a good way for them to make money. The analogue would be an engineer proposing a gold plated submarine instead of doggy paddling across the lake. 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 am going to go on a sarcastic rant here.<p>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?<p>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?
Simpler to define what you want to do as Option B then produce an expensive & time consuming Option A and an unacceptable, risky and business damaging Option C. Then show the Powerpoint to the C-Suite and let them think that going for Option B was their great decision making skills. Everyone leaves happy!
This is ancillary to the discussion but that was a scummy plumbing company. When I became an homeowner I read up on codes and took a few classes on plumbing, electrical and HVAC. A lot of these companies take advantage of the homeowner not being knowledgeable in those areas. Sometimes these people that come over to your house are sales people and not actual tradespeople.
I haven’t seen this work in my experience. If you are going to threaten to delay a project for 6 months you really need to deliver or you are just burning product’s faith in you.<p>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?”<p>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.
...the parable (I hope it's a parable!) with the plumber is atrocious. You have a suspicion of a leak in the water main, and the plumber instead offers to re-do your whole in-house waterworks while evading the question whether there is actually a leak in the main, or whether our current in-house plumbing is failing. Oh, and also lying about the pressure regulators only being settable once, to boot. Just pay through the nose for all those wonderful new shiny things, come on, you planned on renovating your house in the near future anyhow, right?<p><i>Why</i> do you propose to us to be like this?
If there is no product, there is no need of any architecture.
By the way, multiple architectures will give you different product features.
So, what do people need in the product drives the functional architecture, while regulation, performance and pricing will drive the technical architecture.<p>Excessive craftsmanship and over-engineering may kill your product as much as over-selling features may kill the project.
Sometimes product agrees with Client to do something they do not fully understand. If a software engineer fails to detect this part, product will commit to things that are yet to be specified. Client will start writing letters to Santa but all of them will bind.<p>I had been in such situation and it was nightmare
A plumber is not worried about quality and the future well being of the home owner.<p>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.
> This means that you gather up all the information you need to give product exactly what they want, and then you come back to them with an estimate: six easy monthly payments of $2500. Or, rather, you say “One full time mid-level engineer’s time for 6 months on our team, plus one full time engineer’s time from the Infrastructure team.”<p>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?<p>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.<p>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.<p>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.
I reference this post again and again when thinking about these "fun" discussions.<p><a href="https://news.ycombinator.com/item?id=14070189">https://news.ycombinator.com/item?id=14070189</a>
The plumber example is quite good, but I prefer the modern car mechanic that connects a computer to a car and reads out things usually even they don't understand which <i>have</i> to be fixed and no one can explain anything but 'engine bad'.<p>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 <i>talked</i> 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.<p>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.<p>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.<p>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!).
This is exactly what I did.<p>People like to bargin and negotiate, feel the "control". You must start off with an unacceptable price, then talk through "tradeoffs".<p>If you plan it right you can get the exact "tradeoff" you need.
I strongly disagree with this because it infantilises your PM to a ridiculous level.<p>You absolutely <i>should</i> 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.<p>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.<p>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.