5 ms·

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 thing

• ahoef 2y ago
  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."
  • dns_snek 2y ago
    > 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?
    • hiatus 2y ago
      I took it to mean the speed of the product, not developer velocity.
    • actinium226 2y ago
      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).
• jaza 2y ago
  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.
• fallous 2y ago
  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.
  • frant-hartm 2y ago
    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.
    • n_plus_1_acc 2y ago
      I feel the same. I want to make decisions based on facts, not emotional Manipulation.
      • roenxi 2y ago
        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.
• brotchie 2y ago
  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.
  • keithalewis 2y ago
    Doctor, it hurts when I do that.
  • beAbU 2y ago
    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.
    • pas 2y ago
      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..)
  • auggierose 2y ago
    I don't think that destroying yourself mentally and physically should be part of your toolbox.
  • pjc50 2y ago
    .. why would you do that? Martyrdom complex?
    • Woshiwuja 2y ago
      [dead]
  • vundercind 2y ago
• kqr 2y ago
  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.
• roenxi 2y ago
  > 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.
  • gwervc 2y ago
    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).
    • pjc50 2y ago
      Hence the urgent/important matrix: https://todoist.com/productivity-methods/eisenhower-matrix https://todoist.com/productivity-methods/eisenhower-matrix
• pjc50 2y ago
  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)
  • pas 2y ago
    Also, for anyone who's new to this, hierarchical organizations have an informal/shadow hierarchy too, usually an extension of the de jure one.
  • lmm 2y ago
    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.
• jauntywundrkind 2y ago
  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.
• larsrc 2y ago
  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.
  • ghaff 2y ago
    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.
  • pas 2y ago
    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.
• sgarland 2y ago
  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.
  • freedomben 2y ago
    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!
    • sgarland 2y ago
      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?
  • tomjen3 2y ago
    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.
• drewcoo 2y ago
  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.
• wfjackson3 2y ago
  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.
• workflowsauce 2y ago
  I think of this as empathy. Step into their frame, look around, and then come back.