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.
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.
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.
Maybe you already do, but I've had this exact challenge in the past as well and what has worked best is to send them some SQL queries that do it the "right" way. Often times I think they just don't want to deal with the problem: it's hard, it's uncomfortable, and nobody "up the chain" will care about it. There's plenty of reason not to want to do it.
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!
Of the items you listed, I only care about referential integrity (or rather, I don't want things to be wrong). Unless we are adding millions of rows on a daily basis, microoptimizations don't make a meaningful impact.
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.
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."
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).
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.
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)
Nah. All organisations have relationships, and the ones that appear on the org chart are usually a small subset of them. Actual hierarchies are extremely rare, e.g. even in an officially very hierarchical company there will usually be loops because someone nominally low actually controls someone nominally high.
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.
In certain adversarial workplaces this basically gives the other party a perpetual license to blame you and your work for any failures, no matter how circumstantial the link.
Having watched nearly all my work ever basically be thrown away, usually way before it actually provides enough benefits to have been worth the cost, and for reasons that have nothing to do with the quality of the work: yeah, I definitely don’t care enough about anything I make at work to stick my neck out quite that far. There’s professional, then there’s unhealthy.
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.
There’s at least overlap with needs but also what their biggest pain points are currently. One way I’ve often heard it put is sell aspirin not vitamins.
And one thing that usually is cheap - as an architect - is putting yourself into the other's shoes. understand them, their lingo, their model their immediate context (cash flows, promotion, trends, cultural signifiers, business vision, their own career dreams) ... it's the interface you need to be able to actually model the problem.
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.
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?
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.
> 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 a great response. I would add that this is how any larger project gets evaluated and prioritized. In smaller companies, especially startups, I have seen the friction show up when the company is too small to have any staff dedicated to working architecture and engineering facing engineering systems, but big enough that their past choices are creating friction. At that unique point in time, it's really an organizational issue more than anything.
You hit the nail on the head, it's about responsibility and trust, and this is often lacking in various ways when tech feels like they need permission from product to spend time on anything.
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. 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.
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.
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.
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.
That points to everyone being focused on their own goals rather than working together to deliver the product that will satisfy customers the best.
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.
If my job is to prioritize work and understand all the tradeoffs involved in that work, you can be damn sure I'll go understand the tradeoffs. If Product don't understand that technical debt makes things slower, and exactly how much slower it makes them, then they aren't doing their jobs.
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.
Yeah.. I think the problem is when product dictates what is going to be implemented without asking developers if it's feasible. It happens.
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.
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.
You don't need everyone on every team to be a cross-functional thinker, but you need the people who are working cross-functionally to actually think about the big picture and realize they're optimizing for company success and not some arbitrary, often ambiguous goal like "good engineering".
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.
> 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.
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.
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.
> 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.
> 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.
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.
> 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.
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?
Readit News
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.
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!
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.
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.
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.
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.
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.
Deleted Comment
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.
Dead Comment
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.
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.
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?