5 ms·

"An example of uncertainty in business is when your CEO tells you they promised a feature to your biggest client and it needs to be built ASAP as highest priori

"An example of uncertainty in business is when your CEO tells you they promised a feature to your biggest client and it needs to be built ASAP as highest priority, so all hands on deck. Then a day later they tell you another feature, completely contradictory to the first one, needs to be built as well and is also highest priority. When you tell them they both can't be highest priority, the answer is: make it happen." At a certain point you have to just build a queue and start the next highest priority thing next. Too much WIP kills you.

submain 3y ago
As a manager, if upstream changes priorities on me but what we’re working on is almost done, I just go ahead and finish it anyways. When they eventually switch back to the original thing they are always surprised to know it’s been completed.
- classified 3y ago
  Bad tactics. You let them make stupid mistakes with impunity. That way they'll never learn.
AnimalMuppet 3y ago
Worse is when it's a salesman, not the CEO. It's infuriating. I always wanted to tell that salesman that he got to go back to the customer and tell them that we weren't going to do it, since he was the one who promised it without finding out whether and when we could do it. Of course, I never had the clout to force that to happen...
- Clubber 3y ago
  It's always sales it seems. We're doing stuff under the gun right now because sales promised a huge new client we had something that wasn't ready yet. They didn't bother to ask us, they just promised so they could get their commission.
  - ryandrake 3y ago
    Good salesmen can sell the product that we already have. Terrible ones can't, and instead sell a product we don't have and then frantically beg R&D to make that product right away.
    - aledalgrande 3y ago
      Agreed on this. And there's also great people in the middle who keep sales people up to date with new features and deprecations if you want the system to work.
- SketchySeaBeast 3y ago
  I've been so much happier ever since I took a position in an organization that doesn't feature a sales department.
- willcipriano 3y ago
  Speculatively build a feature that you know a customer somewhere would want (but maybe not the customer you have now) and then demand he find someone to buy it within a month before the AWS bills for it are due. "You're costing us a lot of money!"
- btilly 3y ago
  And this is why you need sales engineers. To look at what was promised, see that it meets the customer's needs, and is doable on your end. It isn't just about helping sell the customer. It is also about saying no to overeager salespeople.
csmattryder 3y ago
This was my last job, anyone in this position for any longer than necessary should be looking for another role. You're on a path to burnout or apathy, either way. I called it "Monster of the Week", as I was watching a lot of X-Files at the time. Still like that term for it.
arethuza 3y ago
At one point many years ago I was Director of Engineering for a company that was planning a major new version of their product. After I'd been there a few weeks I said to the CEO that I thought I had a pretty good understanding of the scope and challenges for the new release. The CEO said "no you don't" - which led me to ask why he thought this and he said he had thought up a new "must have" feature over the weekend - which was clearly very technically challenging. He then asserted that anything could be built in 48 hours.... I'm amazed I lasted as long as I did in that job.
- coldtea 3y ago
  The CEO tells the Director of Engineering how long a time a feature "could be built" in? A new one, they suddenly pulled out of their asses too? Why even have a Director of Engineering position then?
  - eschneider 3y ago
    To take the blame, so, so obviously.
    - coldtea 3y ago
      Ah, of course!
  - spacemadness 3y ago
    Because the world of business runs on hubris.
- TheCleric 3y ago
  Reminds me of my Director of Engineering gig where I was asked how quickly we could deliver a new feature that the CTO had thought of. After giving three different estimates on the spot and being told each was “unrealistic” and told to “try again” in a meeting with senior leadership present, I finally said “Just tell me what date you want to hear so we can pretend I said that.” I was chastised for being unprofessional and embarrassing the department. Didn’t care then; no regrets now.
deleted 3y ago
[deleted]
Verdex 3y ago
This is one of the reasons why kanban is my favorite project management methodology. "Ah, new highest priority feature. Lets do a mini discovery session and it looks like this work can be represented with 20 sticky notes. Our historical team velocity is 10 sticky notes every two weeks. So we'll probably be done in four weeks. If we take down all the existing work in progress. Lets go to each existing sticky and you can confirm that we can stop working on it." The stakeholders are still allowed to make decisions, but (hopefully) it forces them to be realistic and understand what they're asking the team to do.
- jacques_chester 3y ago
  Pivotal Tracker does something like this with release markers. You can set markers between any two stories and, optionally, set a date. Tracker does a very simple moving average projection and if the stories before the marker will take too long, it turns bright red. I found it remarkably effective at getting business folks to actually prioritize. They don't believe you, but they'll believe the computer.
koonsolo 3y ago
If both have high priority, it's the same as both have low priority.
fatnoah 3y ago
And, as happened to me recently, the customer states in the demo that it's useless to them and let's just all move on to the next release.
JohnMakin 3y ago
One of the strongest skills as a business facing developer is being able to say no.
- sz4kerto 3y ago
  Many people misunderstand this. Just saying 'no' and being firm won't make you successful, it's not a very useful. Saying 'no' while convincing others that 'no' is actually the best strategy is a great skill.
  - yoyohello13 3y ago
    I like the redirection strategy. Find something easier to do and convince them it's better. Same strategy works for training dogs.
  - BurningFrog 3y ago
    A good way to say "no" is, "yes, but then the thing I'm working on will not be done".
    - cchi_co 3y ago
      [dead]
- epiccoleman 3y ago
  https://grugbrain.dev/#grug-on-saying-no https://grugbrain.dev/#grug-on-saying-no > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer > is ok: how many shiney rock grug really need anyway?
  - Yodel0914 3y ago
    It site is an amazing and hilarious encapsulation of pretty much every conclusion I've come to after programming professionally for 20+ years (except maybe generics)
ijwann 3y ago
This is why good developers are hard to find. There aren't a whole lot of developers who have the required technical abilities while also being able to communicate with clients/leadership effectively. The CEO is doing that because they don't understand how things work in your org. If you're the one communicating with the CEO, then its your job to be persuasive when telling them why what they're asking can't happen the way they're envisioning. If they come back with "make it happen" then you weren't persuasive enough.
layer8 3y ago
That’s not an example of uncertainty in business, it’s an example of incompetence in leadership. The problem is not one of software engineering, it’s one of rampant bad management and business practices.
matrix87 3y ago
> When you tell them they both can't be highest priority, the answer is: make it happen "Quality or quantity?" "Yes" These types are some of the most insufferable people imaginable

submain 3y ago

As a manager, if upstream changes priorities on me but what we’re working on is almost done, I just go ahead and finish it anyways. When they eventually switch back to the original thing they are always surprised to know it’s been completed.

classified 3y ago
Bad tactics. You let them make stupid mistakes with impunity. That way they'll never learn.

AnimalMuppet 3y ago

Worse is when it's a salesman, not the CEO. It's infuriating. I always wanted to tell that salesman that he got to go back to the customer and tell them that we weren't going to do it, since he was the one who promised it without finding out whether and when we could do it. Of course, I never had the clout to force that to happen...

Clubber 3y ago
It's always sales it seems. We're doing stuff under the gun right now because sales promised a huge new client we had something that wasn't ready yet. They didn't bother to ask us, they just promised so they could get their commission.
- ryandrake 3y ago
  Good salesmen can sell the product that we already have. Terrible ones can't, and instead sell a product we don't have and then frantically beg R&D to make that product right away.
  - aledalgrande 3y ago
    Agreed on this. And there's also great people in the middle who keep sales people up to date with new features and deprecations if you want the system to work.
SketchySeaBeast 3y ago
I've been so much happier ever since I took a position in an organization that doesn't feature a sales department.
willcipriano 3y ago
Speculatively build a feature that you know a customer somewhere would want (but maybe not the customer you have now) and then demand he find someone to buy it within a month before the AWS bills for it are due. "You're costing us a lot of money!"
btilly 3y ago
And this is why you need sales engineers. To look at what was promised, see that it meets the customer's needs, and is doable on your end. It isn't just about helping sell the customer. It is also about saying no to overeager salespeople.

csmattryder 3y ago

This was my last job, anyone in this position for any longer than necessary should be looking for another role. You're on a path to burnout or apathy, either way. I called it "Monster of the Week", as I was watching a lot of X-Files at the time. Still like that term for it.

arethuza 3y ago

At one point many years ago I was Director of Engineering for a company that was planning a major new version of their product. After I'd been there a few weeks I said to the CEO that I thought I had a pretty good understanding of the scope and challenges for the new release. The CEO said "no you don't" - which led me to ask why he thought this and he said he had thought up a new "must have" feature over the weekend - which was clearly very technically challenging. He then asserted that anything could be built in 48 hours.... I'm amazed I lasted as long as I did in that job.

coldtea 3y ago
The CEO tells the Director of Engineering how long a time a feature "could be built" in? A new one, they suddenly pulled out of their asses too? Why even have a Director of Engineering position then?
- eschneider 3y ago
  To take the blame, so, so obviously.
  - coldtea 3y ago
    Ah, of course!
- spacemadness 3y ago
  Because the world of business runs on hubris.
TheCleric 3y ago
Reminds me of my Director of Engineering gig where I was asked how quickly we could deliver a new feature that the CTO had thought of. After giving three different estimates on the spot and being told each was “unrealistic” and told to “try again” in a meeting with senior leadership present, I finally said “Just tell me what date you want to hear so we can pretend I said that.” I was chastised for being unprofessional and embarrassing the department. Didn’t care then; no regrets now.

deleted 3y ago

[deleted]

Verdex 3y ago

This is one of the reasons why kanban is my favorite project management methodology. "Ah, new highest priority feature. Lets do a mini discovery session and it looks like this work can be represented with 20 sticky notes. Our historical team velocity is 10 sticky notes every two weeks. So we'll probably be done in four weeks. If we take down all the existing work in progress. Lets go to each existing sticky and you can confirm that we can stop working on it." The stakeholders are still allowed to make decisions, but (hopefully) it forces them to be realistic and understand what they're asking the team to do.

jacques_chester 3y ago
Pivotal Tracker does something like this with release markers. You can set markers between any two stories and, optionally, set a date. Tracker does a very simple moving average projection and if the stories before the marker will take too long, it turns bright red. I found it remarkably effective at getting business folks to actually prioritize. They don't believe you, but they'll believe the computer.

koonsolo 3y ago

If both have high priority, it's the same as both have low priority.

fatnoah 3y ago

And, as happened to me recently, the customer states in the demo that it's useless to them and let's just all move on to the next release.

JohnMakin 3y ago

One of the strongest skills as a business facing developer is being able to say no.

sz4kerto 3y ago
Many people misunderstand this. Just saying 'no' and being firm won't make you successful, it's not a very useful. Saying 'no' while convincing others that 'no' is actually the best strategy is a great skill.
- yoyohello13 3y ago
  I like the redirection strategy. Find something easier to do and convince them it's better. Same strategy works for training dogs.
- BurningFrog 3y ago
  A good way to say "no" is, "yes, but then the thing I'm working on will not be done".
  - cchi_co 3y ago
    [dead]
epiccoleman 3y ago
https://grugbrain.dev/#grug-on-saying-no https://grugbrain.dev/#grug-on-saying-no > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer > is ok: how many shiney rock grug really need anyway?
- Yodel0914 3y ago
  It site is an amazing and hilarious encapsulation of pretty much every conclusion I've come to after programming professionally for 20+ years (except maybe generics)

ijwann 3y ago

This is why good developers are hard to find. There aren't a whole lot of developers who have the required technical abilities while also being able to communicate with clients/leadership effectively. The CEO is doing that because they don't understand how things work in your org. If you're the one communicating with the CEO, then its your job to be persuasive when telling them why what they're asking can't happen the way they're envisioning. If they come back with "make it happen" then you weren't persuasive enough.

layer8 3y ago

That’s not an example of uncertainty in business, it’s an example of incompetence in leadership. The problem is not one of software engineering, it’s one of rampant bad management and business practices.

matrix87 3y ago

> When you tell them they both can't be highest priority, the answer is: make it happen "Quality or quantity?" "Yes" These types are some of the most insufferable people imaginable