4 ms·

Even if you had presented, there was a big chance that SQL Windows would have been chosen anyway. The risk calculation senior leadership would have considered

Even if you had presented, there was a big chance that SQL Windows would have been chosen anyway. The risk calculation senior leadership would have considered delivering anything sooner with iterative improvement versus a long ramp up but with more efficiency. While the first may end up being more expensive, it's less risky and more likely to pay off. The longer and more complicated ramp up a project has higher risk, the more likely it will fail before it even delivers. Leadership is FAR more likely to lean on a sure thing than higher risk/reward. To bypass that you need a proven strong leader and team who delivers big complicated projects and a VERY strong presentation to show the problem was thought out. Even then, competing priorities and other factors may come into the decision making process. And I am not saying I agree with the decision making much of the time, but this is what I have experienced. To be very honest, the only time I managed to get a project like this approved is when I proved with 100% certainty that all the alternatives would fail, why, and how. Even then it took me 1.5 years and significant buy-in from principle engineers to convince senior leadership the it was the only path forward.

guessbest 4y ago
It was easier to get free stuff from Microsoft for choosing their products than the C++ standards committee.
- jodrellblank 4y ago
  https://en.wikipedia.org/wiki/Gupta_Technologies https://en.wikipedia.org/wiki/Gupta_Technologies doesn't seem to have anything to do with Microsoft?
  - guessbest 4y ago
    You're right. I didn't realize they had a SQLWindows tool that wasn't associated with Microsoft. Microsoft used to be real aggressive with their trademark on Windows. > SQLWindows was one of the first GUI development tools for Microsoft Windows.
- Kranar 4y ago
  There was no C++ Standard's Committee in 1993.
  - guessbest 4y ago
    That's the joke.
neoCrimeLabs 4y ago
A friend asked me offline to elaborate on my scenario, answering publicly. We had a gap of about 12 capabilities in our environment. The capabilities were in the same family, but functionally different. To make matters more complicated, different teams/leaders only required 1-3 of the capabilities and did not know about or care about the others. So senior leadership (about 4vp, and a dozen or so directors) saw this as 12 problems that can be solved with 12 solutions. The problem is solving it as 12 solutions required 12x the engineering to implement, 12x to operate, and 12x user support -- actually I'm simplifying, it was worse in reality. The financial cost was also higher but more like 4x. To be solved as a single solution required a far longer ramp up time to a functional solution, but would take significantly less engineering resources at every step. To boot, it would also scale far far better - requiring far less people to operate and scale. So two problems needed to be overcome is convincing leadership that it was not merely a problem of solving their perceived problem of 1-3 capabilities, but 12, and that if we had to support all 12 capabilities we'd need a significantly larger team. Adding to that was the upfront financial cost for a unified solution was more expensive than solving the perceived 1-3 capabilities any leader knew or cared about. The solution was shot down 3 times with me being directly told "This is the wrong solution, please have someone else propose a better solution." And to be very clear, this company actually had good leadership. But with such a large environment they all had their priorities and limited people/budgets to get them addressed with. The problem was they needed to understand a problem existed outside of their domain, a domain they didn't see as as affecting them very much, so they didn't want to dedicate time to learn it. The solution was to convince their trusted advisors. Principle and senior engineers, senior program managers, etc. Politics suck, but they affect any organization with people. The more people you have, the more politics. The more people you affect, the more politics. If your company becomes successful, you will have to ultimately have increased politics. Period.
samhw 4y ago
I’m disposed to liken it to an anytime algorithm (https://en.m.wikipedia.org/wiki/Anytime_algorithm https://en.m.wikipedia.org/wiki/Anytime_algorithm). You want your projects to be as ‘anytime’ as possible, IMHOBOLHE. I think that’s what your comment is driving at: that there’s a significant benefit to a plan that delivers half the benefits if it only runs for half the (eventual, real; not planned) time, vs a plan that requires a long investment of time but only - hopefully - pays off in full right at the end.
dustingetz 4y ago
Law of Focus

guessbest 4y ago

It was easier to get free stuff from Microsoft for choosing their products than the C++ standards committee.

jodrellblank 4y ago
https://en.wikipedia.org/wiki/Gupta_Technologies https://en.wikipedia.org/wiki/Gupta_Technologies doesn't seem to have anything to do with Microsoft?
- guessbest 4y ago
  You're right. I didn't realize they had a SQLWindows tool that wasn't associated with Microsoft. Microsoft used to be real aggressive with their trademark on Windows. > SQLWindows was one of the first GUI development tools for Microsoft Windows.
Kranar 4y ago
There was no C++ Standard's Committee in 1993.
- guessbest 4y ago
  That's the joke.

neoCrimeLabs 4y ago

A friend asked me offline to elaborate on my scenario, answering publicly. We had a gap of about 12 capabilities in our environment. The capabilities were in the same family, but functionally different. To make matters more complicated, different teams/leaders only required 1-3 of the capabilities and did not know about or care about the others. So senior leadership (about 4vp, and a dozen or so directors) saw this as 12 problems that can be solved with 12 solutions. The problem is solving it as 12 solutions required 12x the engineering to implement, 12x to operate, and 12x user support -- actually I'm simplifying, it was worse in reality. The financial cost was also higher but more like 4x. To be solved as a single solution required a far longer ramp up time to a functional solution, but would take significantly less engineering resources at every step. To boot, it would also scale far far better - requiring far less people to operate and scale. So two problems needed to be overcome is convincing leadership that it was not merely a problem of solving their perceived problem of 1-3 capabilities, but 12, and that if we had to support all 12 capabilities we'd need a significantly larger team. Adding to that was the upfront financial cost for a unified solution was more expensive than solving the perceived 1-3 capabilities any leader knew or cared about. The solution was shot down 3 times with me being directly told "This is the wrong solution, please have someone else propose a better solution." And to be very clear, this company actually had good leadership. But with such a large environment they all had their priorities and limited people/budgets to get them addressed with. The problem was they needed to understand a problem existed outside of their domain, a domain they didn't see as as affecting them very much, so they didn't want to dedicate time to learn it. The solution was to convince their trusted advisors. Principle and senior engineers, senior program managers, etc. Politics suck, but they affect any organization with people. The more people you have, the more politics. The more people you affect, the more politics. If your company becomes successful, you will have to ultimately have increased politics. Period.

samhw 4y ago

I’m disposed to liken it to an anytime algorithm (https://en.m.wikipedia.org/wiki/Anytime_algorithm https://en.m.wikipedia.org/wiki/Anytime_algorithm). You want your projects to be as ‘anytime’ as possible, IMHOBOLHE. I think that’s what your comment is driving at: that there’s a significant benefit to a plan that delivers half the benefits if it only runs for half the (eventual, real; not planned) time, vs a plan that requires a long investment of time but only - hopefully - pays off in full right at the end.

dustingetz 4y ago

Law of Focus