3 ms·

I have been familiar with the author and this article for a long time. > It's not a lack of skill on the part of the expert, it's the lack of skill on the part

I have been familiar with the author and this article for a long time. > It's not a lack of skill on the part of the expert, it's the lack of skill on the part of everybody else This is a very poor frame of reference. It's not other people's fault they cannot understand the value you provide, it's your fault. The thing that tends to bother engineers is that articulating your value (I.e. sales and marketing) is generally orthogonal to your key competencies.

brookst 3y ago
I see this so often: engineers who think it’s demeaning to explain deeply technical things in business terms, so they refuse. Like it’s somehow noble to only speak one language.
- mgkimsal 3y ago
  > engineers who think it’s demeaning to explain deeply technical things in business terms, so they refuse I can, and have, explained 'deeply technical things' in 'business terms'. And people understood. Then made a bad/poor/wrong choice anyway, because... "well... all those things you're saying might happen, they might not. Or... it may not happen for months or years, and we already committed to date X for project Y". I can tell people the cost of punting on 'deeply technical thing' will be enormous, like... "this will require doubling the dept headcount and stopping all new progress for 6-12 months". Then offer alternatives. Then get summarily ignored, and watch things crash months later, and the dept is then stuck for months scrambling to understand all the problems they could have avoided. The decision maker who decided for extremely short term gain? They're gone (sometimes of their own choosing, sometimes not). The "risks" can seem wildly out of touch with reality, but many times if you're making poor choices you do hit the "worst case scenario" wall. Colleague has been contracting inside a shop on and off for a few years. He indicated "if we don't do X, we will not be able to do any new feature development for at least 18 months". And... closing in on 4 years later, they've not shipped any substantial new features (some bug fixes, but that's about it). I've seen this happen once up close, and have seen inside other companies and got the war stories from others. Does this happen every single time? Of course not. But even if you can confidently and correctly and pleasingly describe deep tech things to business folks in their own language, showing the pros/cons/costs/risks... that doesn't mean they will take your side. Saving face, hitting deadlines at all costs, and other factors weight on decisions, and you can't control that. You can control where and how you work though.
  - jiggawatts 3y ago
    My equivalent of this was finding a brand new SAN array had been formatted wrong. It was nearly empty and unused so it would have been a 5-minute job to format 99% of it and shuffle the in-use 1% around so that the rest can be fixed too. Both the storage vendor tech and I vehemently argued for solving this immediately but were told to “do it later”. I pointed out that “later” would be when it is full and has 10K production users using it 24/7. Hence any reformatting would be a six-month project requiring additional kit for the scratch space needed. Not to mention the risk! I was wrong. It took 12 months.
  - brookst 3y ago
    Yes? The position is not that being a good communicator guarantees perfect results every time. The position is that intentionally being a bad communicator guarantees poor results most of the time. Same way that not driving drunk does not guarantee you won’t get in a wreck.

brookst 3y ago

I see this so often: engineers who think it’s demeaning to explain deeply technical things in business terms, so they refuse. Like it’s somehow noble to only speak one language.

mgkimsal 3y ago
> engineers who think it’s demeaning to explain deeply technical things in business terms, so they refuse I can, and have, explained 'deeply technical things' in 'business terms'. And people understood. Then made a bad/poor/wrong choice anyway, because... "well... all those things you're saying might happen, they might not. Or... it may not happen for months or years, and we already committed to date X for project Y". I can tell people the cost of punting on 'deeply technical thing' will be enormous, like... "this will require doubling the dept headcount and stopping all new progress for 6-12 months". Then offer alternatives. Then get summarily ignored, and watch things crash months later, and the dept is then stuck for months scrambling to understand all the problems they could have avoided. The decision maker who decided for extremely short term gain? They're gone (sometimes of their own choosing, sometimes not). The "risks" can seem wildly out of touch with reality, but many times if you're making poor choices you do hit the "worst case scenario" wall. Colleague has been contracting inside a shop on and off for a few years. He indicated "if we don't do X, we will not be able to do any new feature development for at least 18 months". And... closing in on 4 years later, they've not shipped any substantial new features (some bug fixes, but that's about it). I've seen this happen once up close, and have seen inside other companies and got the war stories from others. Does this happen every single time? Of course not. But even if you can confidently and correctly and pleasingly describe deep tech things to business folks in their own language, showing the pros/cons/costs/risks... that doesn't mean they will take your side. Saving face, hitting deadlines at all costs, and other factors weight on decisions, and you can't control that. You can control where and how you work though.
- jiggawatts 3y ago
  My equivalent of this was finding a brand new SAN array had been formatted wrong. It was nearly empty and unused so it would have been a 5-minute job to format 99% of it and shuffle the in-use 1% around so that the rest can be fixed too. Both the storage vendor tech and I vehemently argued for solving this immediately but were told to “do it later”. I pointed out that “later” would be when it is full and has 10K production users using it 24/7. Hence any reformatting would be a six-month project requiring additional kit for the scratch space needed. Not to mention the risk! I was wrong. It took 12 months.
- brookst 3y ago
  Yes? The position is not that being a good communicator guarantees perfect results every time. The position is that intentionally being a bad communicator guarantees poor results most of the time. Same way that not driving drunk does not guarantee you won’t get in a wreck.