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.
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.
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.
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?
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.
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.
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?
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.
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.
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"
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.
> 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!
I do this when I can, certainly, but there are only so many hours in a day, and I have larger tasks to deal with much of the time.
What I’d love is for devs to treat SQL the same as they would their primary language, instead of some mysterious and arcane artifact to be abstracted away and ignored. If I refused to use any data structure other than a dict / hashmap because “it’s good enough,” how do you think that would go over?
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.
> Unless we are adding millions of rows on a daily basis, microoptimizations don't make a meaningful impact.
At toy scale (if your entire dataset can easily fit into memory on a small instance; probably < 100,000,000 rows total), then some things don’t matter as much. I disagree that they aren’t meaningful, though. Especially with Aurora, and its “what if we added even more latency to queries” model of splitting compute and storage. Go make a table with a few million rows; one column with a sequential ID, the other with UUIDv4. Index them both (in MySQL, you’d need to swap PKs between tests since it clusters), then do any kind of aggregation query, like COUNT,
MAX, etc. That’s not a small difference.
A micro-optimization for an RDBMS would be something like switching a MySQL column from VARCHAR to CHAR if you’re positive that the length is fixed, to save the 1-2 bytes/row overhead. It matters at scale (thousands of tables * millions of rows can add up), but not for most.
> 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.
People always say this as though it’s fact, but I’ve yet to see any studies on it, and frankly I doubt its veracity. Take the current RDS pricing for on-demand Postgres, r7g.large vs. r7g.xlarge: in us-east-1, it’s $0.239/hr vs. $0.478/hr. That difference works out to about $2000/yr, for a single-AZ DB of the smallest non-burstable type they have. Since microservices remain all the rage, multiply that by N. You’re telling me it’s not worth the money to spend a few hours reading docs and applying the knowledge? I don’t buy it. Moreover, as someone who enjoys the craft of SWE, it’s physically painful to watch people say “eh, let’s just throw money at it” instead of understanding where their code is slow, and solving it.
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).
I've noticed no one seems to look at number of PRs per week or average length of time and MR is open. Those seems like they should be good metrics for both how well a team is collaborating and how fast they're moving (perhaps normalized by LOC in the MR, but then again smaller MRs tend to go through faster so maybe LOC is already reflected in the metric).
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.
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.
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.
> 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.
It's funny you say that. My career hasn't been as wide and varied as many. My roles have been across wildly different industries, but I only have one person's life to live and my average tenure has been around 5 years. I've had a lot of time to reflect on these sorts of issues in depth, but not to see how they apply across as many situations.
That _exactly_ describes the organizations I had in mind when I was writing that. I have no extra useful insight to add or anything, just that you've definitely given me something to chew on there.
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.
> 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.
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>".
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.
But the people in cross-functional roles are still being drawn from a probability distribution in which most people are unable to think cross-functionally.
> 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?
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.
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.
Because people tend to want to see options and be involved in the decision making process, especially if they're ultimately responsible for the work and its cost. For a similar reason as an architect I don't define in a ticket the exact code changes a developer should do, instead I define the intention, the reason perhaps make a suggestion and then we discuss.
And if they choose option C we make sure there's a paper trail to cover our asses and then a bit later find a reason to revisit the decision.
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.
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.
If nothing else, This Old House will teach you how fast you should run away from a house with water damage if you don't own it. Which is, "knock your grandmother down if she's in the way" fast.
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.
...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?
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.
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 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.
This is where the less than premium options come into play isn’t it? You can present product with a plan of what they want, and the consequences and cost. You should also present them with other options, which could be an extra toilet or sink. Then you let product and the customer decide if they actually want the full thing or not.
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.
Your comment has big “you’re just ticket monkeys” energy.
> 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
Let me know how the plumber reacts when you then tell him said bathroom needs to be freestanding 300m in the air, and the plumbing needs to be made out painted twigs and twine (because your housemate thinks they look pretty), and you also want heated stone floors and you have a budget of $250 and an ice-cream wrapper.
In the miraculous case said plumber accepts the job, make sure to change specs halfway through.
This is not what I said at all. I completely agree with the article on how you should present options to product and the customer, and then let them decide. In your example product and the customer comes with the solution on how to build it and what budget is needed to you. If you’re staying out of product and customer, then they should stay out of engineering.
In your case it would be your job to figure out how it could be done, figure out other cheaper options and then present them with clear outlines on what each option would cost. If you get a budget pushed on you from something like sales, then your organisation is dysfunctional similar to what GP was suggesting. (I’m obviously not suggesting that this doesn’t happen.)
> 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.
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.
> 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.
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!).
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.
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.