Often times, when we are working on a project with a well defined set of milestones, we’ll be asked to add something to the list of tasks. These asks may be simple and quick, or long and time consuming.
One thing each ask does, is increase the scoping of the milestone, increase the risk surface, and add additional criterion to the milestone. This means, each ask needs careful thought on the net increase in risk versus the net increase in value, or net loss to opportunity cost by not acting on the ask.
If you are on the asking side, you need to consider is the ask going to increase the project risk. Do you really need this ask completed now, or is it, quite frankly, an attempt to show that you have influence over the project. If it is not needed, then why are you pushing it? Put another way, if it is not needed at that moment, runs contrary to the goals of the project to insert this ask now without review and consideration by all parties, what specifically is the business purpose of the ask? If you don’t have a good argument as for why this ask must be done now, you need to reconsider making the ask.
Similarly on the execution side, all asks need to be pre-identified with mechanisms and a protocol for handling new asks. During critical phases, significant changes result in unbounded risk. You as a CTO, or project leader, or whatever your role is, when you have to evaluate the ask coming in, is to look at the risk/benefit and risk/loss scenarios. Use the technical domain knowledge from your team, specifically to inform the business process.
This said, some of us who’ve been doing this a while, know that the correct answer to new asks at critical junctures is “no”. Solid projects finalizing critical milestones under very tight timing conditions, with specific risk/loss profiles, and no perceivable near term benefit … more importantly, the opportunity cost of performing the ask now vs later is 100% on increasing the risk side of the equation, with no actual benefit to be had performing this ask early … we know, the actual importance of saying “no”.
A strong technical business leader will say “no” here. To do otherwise jeopardizes the project milestones, and allows things that should not continue to creep the scope, to do exactly that.
I am a person who gets stuff done. I get it done efficiently, and when I say I will make X work, I am putting my reputation on the line when I do it. And I make it work. Not braggadocio. Just a solid track record. My failures involve raising capital for businesses, and selling businesses. But I know how to build, manage, and support #HPC , #storage , #AI , and accelerated systems, bring them to operational states to pass specific milestones, and (often wildly) exceed expectations.
When I say “no”, there is a very good reason for it. It’s not out of spite. It’s not out of malice. It’s out of a long history of knowing where the bear traps are that are quite likely to mess you up badly from a technical and business perspective.
Saying “no” is often a very important business step in the process. You need well defined gates for transition between stages. If you allow scope and work creep to blur your gates, you will be stuck at specific gates, as you add new risks to your gate traversal.
Saying “no” also prevents bike-shedding from occurring during these phases. Or biases or personal preferences from impacting the gate traversal and state transitions. It prevents adding additional requirements to a gate that have not been agreed to by all parties. It prevents adding risk at inopportune moments.
The importance of saying “no” at critical junctures cannot be overstated.
 imagine trying to raise capital to build inexpensive hardware accelerators on PCI cards back in, I dunno, 2002-2006 or so. No one in VC land believed they would be relevant. Fast forward to 2019. Accelerators. Everywhere.
When you are right, you are really right.
 See https://scalability.org/2017/03/requiem/ . We had tried selling the company to Cray, to Quantum, and spoken to a few others. Our bank shot us in the head, sold off all the assets.