4 ms·

> We were constantly faced with product leaders (VPs of Product, CPOs, PMs, etc.) who were very excited about adding Cord to their existing product. They saw th

by twic 1y ago

> We were constantly faced with product leaders (VPs of Product, CPOs, PMs, etc.) who were very excited about adding Cord to their existing product. They saw the value unambiguously. And then we’d get to the dev team and face a stonewall of NIH syndrome alongside a clear preference for building it all themselves, even when that meant shipping a vastly less-useful product to their end users. From the other side, this looks like "management signed up for some flashy product based on marketing, but it turned out to be useless". Not recognising that seems like a substantial blind spot. It would be interesting to hear from anyone who evaluated Cord and decided not to use it. I wonder if the risk that the company might fold entered into the decision. Still, excellent of them to have open-sourced it; it superficially looks like they've put a lot of effort into making it usable.

sarreph 1y ago
I find that an uncharitable take to assume lack of usefulness. It’s more likely literally what the author says - getting engineers onboard for something they themselves didn’t choose is difficult. I’ve been in the same position - lots of buy in from leadership / solving a real problem and providing real value. Then it takes months to implement due to having to corral a dev team who simply doesn’t care about your integration.
- twic 1y ago
  Whereas i find that rather uncharitable towards the customers' engineers!
- secstate 1y ago
  The tone here suggests deep misalignment of leadership and ICs. How can you end up enthusiastic about a direction at leadership level and have the ICs "not care," in a functional organization? That's a rhetorical question.
the__alchemist 1y ago
Same impression, after a skim of the Github. Looks like a net complexity add in most cases, if I understand its Readme correctly. Due to the software culture I've been exposed to, especially in web-dev, I am cautious about any level of indirection added by third parties. They may seem like a value-add to first-order, but when managed in the context of a larger system, tend to make performance worse, debugging more difficult, and modifications high-inertia. Not as a principle, but based on observations. For example, When I see text like this: > With pre-built components for chat, presence, and notifications, as well as fully customizable UI primitives, Cord enables rapid implementation of sophisticated, in-app collaboration tools. my pattern-matching brain thinks This is probably going to be slow, require the user to download a large amount of data, and may or may not reduce code required to implement, and will make customization and modification tedius. Maybe this isn't true for this particular library, but it seems to be a good rule, currently.
- ryandrake 1y ago
  Kind of typical in enterprise software. The software vendor puts all of their skill points into Charisma and sells the CxO level people on the product, sometimes to the detriment of the people lower on the totem pole who actually have to work with it.
  - paleotrope 1y ago
    Mgmt: It's got an API! It's got RBAC! It's Perfect! Devs: It sucks ass.
    - jgbbrd 1y ago
      Honestly, you're not miles off. Though with developers, it was actually more the "gotcha" variety of "It sucks ass". We would have a senior dev on the dealing-making-or-breaking call and he would say something like, "Wait -- sorry, do you support <specific thing that our system doesn't have>?" We would say honestly that we don't have that yet. Then the senior dev would say, "Ooohh.... sorry... yeah... we need (per-message arbitrary data storage | support for on-prem | real-time analytics | per-messsage privacy controls | etc.)." We eventually had to face the reality that one of two things must be true: 1) The market is just too fragmented such that there cannot exist one product that serves it 2) The devs involved really, really don't want to give a product like this a chance because they actually want to build fun features like this themselves and they're (rightfully) skeptical that some random startup can do it better As I sit here now, I have some confidence that it's 75% #2 and 25% #1. Anyway, the basic shape of the sales calls went a lot like what you're saying.
abxyz 1y ago
Most employees are unmotivated and mediocre-at-best, across every role and industry because most people are (rightly) just showing up to get paid. Engineers are no different, we are not special. Most engineers do not have the incentive to go out of their way to improve their product when keeping this as-is is easier for them. Regardless of whether the OPs product is good, almost all of the engineer opposition would come from engineers not wanting to deal with integrating some new thing that non-engineers want because it’s more work. If you think most engineers are evaluating things based on the value it’ll drive for their product, you’ve lived a lucky career (and long may it continue).
- tsimionescu 1y ago
  An engineer's job is to add the features that management asks to be added. Engineers who fight with management decisions on adding features to a product are almost always exactly the ones who care a lot about the product - the path of last resistance is to just do what you're asked, since that's what you're paid for. Management wants to add Google ads to their premium offline app? Sure, they'll work to add that, who cares. Whether they spend two months building this feature or another, they're getting paid the same amount.
  - bee_rider 1y ago
    > An engineer's job is to add the features that management asks to be added. I get the context here (you are talking about software engineers, fine, and adding silly chat features, which is pretty low stakes). But, still, want to mention the general case: The engineer’s professional obligation is to push back against the company if they are asked to design something impossible (and try to find some alternative that fits the customer’s business need if that’s possible), and to refuse or possible whistle-blow if asked to do something unethical/harmful to society. We live in a very corporatized society where professions are being turned into jobs left and right. But, the engineer’s job is to just implement management’s requests in the same way that the doctor just exists as a conduit to your insurance company: that’s the way the company would like it.
  - ryandrake 1y ago

by twic 1y ago

sarreph 1y ago

I find that an uncharitable take to assume lack of usefulness. It’s more likely literally what the author says - getting engineers onboard for something they themselves didn’t choose is difficult. I’ve been in the same position - lots of buy in from leadership / solving a real problem and providing real value. Then it takes months to implement due to having to corral a dev team who simply doesn’t care about your integration.

twic 1y ago
Whereas i find that rather uncharitable towards the customers' engineers!
secstate 1y ago
The tone here suggests deep misalignment of leadership and ICs. How can you end up enthusiastic about a direction at leadership level and have the ICs "not care," in a functional organization? That's a rhetorical question.

the__alchemist 1y ago

Same impression, after a skim of the Github. Looks like a net complexity add in most cases, if I understand its Readme correctly. Due to the software culture I've been exposed to, especially in web-dev, I am cautious about any level of indirection added by third parties. They may seem like a value-add to first-order, but when managed in the context of a larger system, tend to make performance worse, debugging more difficult, and modifications high-inertia. Not as a principle, but based on observations. For example, When I see text like this: > With pre-built components for chat, presence, and notifications, as well as fully customizable UI primitives, Cord enables rapid implementation of sophisticated, in-app collaboration tools. my pattern-matching brain thinks This is probably going to be slow, require the user to download a large amount of data, and may or may not reduce code required to implement, and will make customization and modification tedius. Maybe this isn't true for this particular library, but it seems to be a good rule, currently.

ryandrake 1y ago
Kind of typical in enterprise software. The software vendor puts all of their skill points into Charisma and sells the CxO level people on the product, sometimes to the detriment of the people lower on the totem pole who actually have to work with it.
- paleotrope 1y ago
  Mgmt: It's got an API! It's got RBAC! It's Perfect! Devs: It sucks ass.
  - jgbbrd 1y ago
    Honestly, you're not miles off. Though with developers, it was actually more the "gotcha" variety of "It sucks ass". We would have a senior dev on the dealing-making-or-breaking call and he would say something like, "Wait -- sorry, do you support <specific thing that our system doesn't have>?" We would say honestly that we don't have that yet. Then the senior dev would say, "Ooohh.... sorry... yeah... we need (per-message arbitrary data storage | support for on-prem | real-time analytics | per-messsage privacy controls | etc.)." We eventually had to face the reality that one of two things must be true: 1) The market is just too fragmented such that there cannot exist one product that serves it 2) The devs involved really, really don't want to give a product like this a chance because they actually want to build fun features like this themselves and they're (rightfully) skeptical that some random startup can do it better As I sit here now, I have some confidence that it's 75% #2 and 25% #1. Anyway, the basic shape of the sales calls went a lot like what you're saying.

abxyz 1y ago

Most employees are unmotivated and mediocre-at-best, across every role and industry because most people are (rightly) just showing up to get paid. Engineers are no different, we are not special. Most engineers do not have the incentive to go out of their way to improve their product when keeping this as-is is easier for them. Regardless of whether the OPs product is good, almost all of the engineer opposition would come from engineers not wanting to deal with integrating some new thing that non-engineers want because it’s more work. If you think most engineers are evaluating things based on the value it’ll drive for their product, you’ve lived a lucky career (and long may it continue).

tsimionescu 1y ago
An engineer's job is to add the features that management asks to be added. Engineers who fight with management decisions on adding features to a product are almost always exactly the ones who care a lot about the product - the path of last resistance is to just do what you're asked, since that's what you're paid for. Management wants to add Google ads to their premium offline app? Sure, they'll work to add that, who cares. Whether they spend two months building this feature or another, they're getting paid the same amount.
- bee_rider 1y ago
  > An engineer's job is to add the features that management asks to be added. I get the context here (you are talking about software engineers, fine, and adding silly chat features, which is pretty low stakes). But, still, want to mention the general case: The engineer’s professional obligation is to push back against the company if they are asked to design something impossible (and try to find some alternative that fits the customer’s business need if that’s possible), and to refuse or possible whistle-blow if asked to do something unethical/harmful to society. We live in a very corporatized society where professions are being turned into jobs left and right. But, the engineer’s job is to just implement management’s requests in the same way that the doctor just exists as a conduit to your insurance company: that’s the way the company would like it.
- ryandrake 1y ago