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.
That's why I hate sales people. Give me all the info on your product, ideally, make it easy to compare to others and I will decide myself.
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.
Most people don’t operate this way. Choice is painful and induces anxiety. There’s a high chance of getting buyers remorse even if you chose the „objectively best” model.
A good salesperson will make sure the choice process is relatively quick and painless. You will feel good afterwards knowing that all the 125 aspects that differentiate this model from the other ones are not that important. The one you chose runs your favourite apps, integrates well with your car and your home entertainment system.
Understanding this and learning how to sell helps in life, incl. negotiating architectural changes with non technical decision makers.
> A good salesperson will make sure the choice process is relatively quick and painless.
The best salesperson isn't the one whose customers are leaving the shop smiling just like a TV advert where buying X or Y will solve every problem in life, but rather the one whose customers leave the shop angry after having purchased this or that product or service, because that is an indicator they were squeezed until just before the point they tell the seller to stick their product somewhere and leave for the competition. Not that I like it, but that is how I see it.
This isn’t zero sum.
what makes you think that this is the best way to obtain loyal and more customers?
Depends on the market of course, but scarcity, either natural or artificial, can do wonders.
Prisoners Dilemma vs Iterated Prisoners Dilemma.
Low trust == maximize mechanical power and optimization
Higher trust == invest time, relationship-building and lower individual transaction profit over a larger volume of profit
Few consumer sales interactions fall into the second category.
prisoner’s dilemma is a dilemma for a reason: it optimizes the total outcome badly. maybe this is why the pessimization of the modern business cycle everyone loves to cry about always works out that way — we’re all interacting in a commons where trying to screw everyone else as hard as possible is the rule, not the exception.
I don’t understand why you’re downvoted. It’s absolutely true that most people don’t like making purchasing decisions by privately comparing spec dumps, even though many programmers enjoy that.
You're telling me some people out there don't create spreadsheets and a scoring system to compare 10 different ceiling fans before purchase?
Absolutely not. It should be abstracted out enough that it can be applied to all purchases and not just ceiling fans. Otherwise, you're going to be duplicating effort for the next purchase and you don't want to have to repeat yourself.
I was actually thinking of scaling to a site first, and then expand horizontally to all ceiling-mounted products. Because what's the point if I can't monetize my decision-making system?
"give all the info on your product"
Exactly except:
If you're a CEO, the info you care about is one set of info.
If you're a user, the info you care about is different.
If you're some other influencer, the info you care about is different again.
Everyone wants different sets of info. Good sales is figuring out what that is and giving it to you.
I feel the same. I want to make decisions based on facts, not emotional Manipulation.
That isn't emotional manipulation. It is what would get called "good communication" or maybe even "empathy" on a slow day. If someone is talking to a salesperson it can't reasonably be seen as manipulation when they explain why said person should buy the thing. That is the point of the conversation.
How do you obtain objective facts about a product?
If I buy a washing machine, it has a fixed known volume, weight capacity, power consumption, noise level. These are objective facts, no? Do you think we can have different opinions on how many kilos of clothes it can take, and be both right?
They would come from the manufacturer manual or a spec sheet or something like that.
Windows has some objective, known, minimum hardware requirements. Are they open to interpretation?
What kind of products are you buying that make you wonder how to get objective facts about them?
Give me the info by email. I hate it when they try to get me on the phone.
Absolutely, me too. They push hard for the phone because many of the sales tactics don't work with email because they're based on non-verbal cues and subtle detection/exploitation. For example, many salespeople are trained to closely watch the person's face and identify what lands and what doesn't and dynamically adapt.
They also want to be able to pressure you for "next steps" or the "follow up" meeting.
I get it, a call can be a lot more efficient for a discussion. There are certainly legitimate reasons to prefer a call to an email. But it reminds me a lot of big tech companies seizing to things like "security" as an ~excuse~ justification for doing things that benefit them. I know the motives aren't pure, and that bothers me.
Why have we developed a system of organizing engineering work that is based on engineers having to sell ideas to their colleagues?
Because their work impacts other people and therefore requires other people to be on board with it?
Unless you're a 1 person company, nothing you do ever only impacts you.
Even a 1 person company has customers.
It’s really weird to me that people have such a hard time imagining a world without “scaled agile” and debate over duplo-scale priorities between product managers and nerds every two weeks. In a sane world, these kinds of decisions would not be a pseudo-democratic negotiation.
The fact that you have to explain this is somewhat concerning.
Usually people say that people skills are as important for having lots of impact as technical skills, but the bar for people skills is really low sometimes I guess.
I feel this. The situation would be more obvious if it was framed as "how to make the organization give a shit about the organization's architectural proposals"
Economics.
In a way, but I have a feeling the conquest of work-life by people who don’t understand the directly-productive work the company does is a result of economics operating in the 1980s—present era of unshackled M&A. It’s a regulatory outcome.
are you trying to suggest that Darwinian selection is the most efficient way to organize a collective to achieve a goal?
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.
> 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.
Urgency isn't a good metric in the corporate world because basically everything is called urgent all the time (spoiler: most of the time it's not).
Hence the urgent/important matrix: https://todoist.com/productivity-methods/eisenhower-matrix
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."
> product speed is declining, see this chart.
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?
I took it to mean the speed of the product, not developer velocity.
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! 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.
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)
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.
Also, for anyone who's new to this, hierarchical organizations have an informal/shadow hierarchy too, usually an extension of the de jure one.
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.
depending on how much weight their voice has it might well worth the risk. (as you gain naysayers but you also deliver results, and that might make certain important folks happy, or at least it will look good on your resume, etc..)
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.
I don't think that destroying yourself mentally and physically should be part of your toolbox.
.. why would you do that? Martyrdom complex?
Doctor, it hurts when I do that.
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.
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.
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.
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.
> 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.
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.
> I think the problem is when product dictates what is going to be implemented
I don't think of that as a problem, that's one of the primary goals of product. Problems (yuuge problems) arise when product also gets to dictate cost/timelines. Sorry, that breaks basic management principles.
> I used to do that until I had a manager that changed my view.
Small, young teams (e.g. startups) can easily do without management, because communication is unhindered and ad-hoc. The more organization expands and matures, the more communication suffers. That's the primary goal of engineering management - facilitate conversations. When I have a request that is tad too technical I always try to backtrack and ask what's the business goal. I am 99% certain "display memory usage per tab" is not the business goal. "Find resource hungry tabs" sounds like a good candidate for a business problem.
"Customers" (e.g. product) tend to be "helpful" and provide technical implementation details, diluting the business problem, while engineering tend to fixate on those implementation hints as if they were technical requirements. Ever noticed how technically inept product managers/owners sometimes tend to be good managers? Well, they are either aware of their technical ineptitude or are inept so much that they can't even express technical details and form their requirements as business questions which leaves implementation details open and allows engineering to implement things "correctly". It's magical how simply communicating on appropriate abstraction level can lead to awesome results as each team can focus on what they are strongest at.
Some of this is what stackoverflow calls an X/Y problem; someone has a problem, got halfway down a route to a solution, and now is talking to you. It can be quite difficult to dig down into what the actual original problem was, then persuade them to back up and pursue what is in your opinion a better solution.
How and what did your manager change your view to?
Very briefly, I resisted implemented features that wouldn't work perfectly. The memory use example was a real one (I was working on a profiler of some complex AI hardware). My boss would say things like "can we report how much memory this operation uses", and I would say "no because some of it is shared with other operations or only live for part of the program run etc.".
He didn't really say anything to change my mind, he just kept asking for things that would be useful to customers and eventually I realised that even if we can't give an answer that makes perfect sense or doesn't work all the time, we can still do better than nothing. Very often something that is roughly right and can be shown some of the time is better than something that doesn't exist at all.
It kind of sounds obvious when I put it like this, but you'd be surprised how often you see "we can't do this very useful thing because <minor flaw that means it won't always work perfectly>".
This is a garbage take. I'll write more later.
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.
This line at the end of the article triggered me:
> 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.
In a "perfect" scenario the product would not require any more development and thus development could be reduced to zero.
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!
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.
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.
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?”
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.
If you are building software to build a product, you are on the product team.
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.
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.
Excessive craftsmanship and over-engineering may kill your product as much as over-selling features may kill the project.
You need to find common incentives, if they don't exist then try to create them.
...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?
Why do you propose to us to be like this?
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.
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 believe Home Depot runs classes on various DIY type things; I've never taken one but I've seen classes listed when I'm walking in the front door.
YouTube and a willingness to experiment will take you a really long way. ElectricianU was really good for learning about the electricals. I've been in this house for a decade now, and I pretty much do everything on it including a down to the studs remodel of a bathroom and kitchen, re-running and adding electrical circuits (replacing and pig-tailing aluminum)... I'm on the fence about whether I'd replace the furnace when it's time, it will need a new intake/exhaust run, but otherwise should be fairly straightforward I'd think. I did just pay for a new roof.
Just be patient with it, it will take longer than you'd like and longer than you'd expect, especially if you can only fit in time on weekends to work on projects. I never seem to have much gumption left after work.
YMMV related to pulling permits. Our local building dept is really easy to work with as a DIYer.
I’ve been a homeowner for a mere two years and I’ve discovered many things wrong with my house. YouTube has a video outlining what I need to fix and how to fix it 90% of the time. Tradespeople get called for the remaining 10%. It’s possible a class with a curriculum and structure would help but YouTube has what you need for ad hoc homeowner issues.
Binging old episodes of This Old House will give you about the same level of understanding that a football fan has of his favorite sport. You won’t necessarily be able to fix things but you’ll know something isn’t right.
That's an excellent analogy. I'd push it further to say that there are YouTube channels (like QB School, to stick to football) that can take you to level 2.
A plumber is not worried about quality and the future well being of the home owner.
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.
Then you have a mediocre developer not willing to align his interests with those of the company. Cannot end well.
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.
I had been in such situation and it was nightmare
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.
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.
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.
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.
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.
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?
The “plumbing” community on reddit. That’s the naming scheme reddit uses.
That's how Reddit is organised.
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?
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.
> 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.
> 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.
> 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.
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.
Only 10 files? Must be nice!
It's a small service and we were a small company...
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.
> 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.”
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?
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.
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.
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.
This is exactly what I did.
People like to bargin and negotiate, feel the "control". You must start off with an unacceptable price, then talk through "tradeoffs".
If you plan it right you can get the exact "tradeoff" you need.
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 have to be fixed and no one can explain anything but 'engine bad'.
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 talked 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.
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.
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.
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!).
Ok but what does this have to do with the topic?
The author argues this is a negotiation and that this is something reasonable and well thinking humans do with eachother; maybe they do in some magical HN dreamed up places, but most of the world is not like that; there is often no negotiation, not between plumber and client, not between car mechanic and client and not between dev and product/client.
But we don't know how most of the world is. It might be that the author of the comment works in a particularly bad place, of which there are many of course.
I strongly disagree with this because it infantilises your PM to a ridiculous level.
You absolutely should 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.
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.
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.
Be outcome oriented