15 Comments
User's avatar
Abdul Ahad's avatar

Really insightful take. As someone growing up in this AI wave, I do a lot of vibe coding and often run into security vulnerabilities, especially when code is reused by others. Fixing those issues later can sometimes hurt the UX, like having to add extra friction such as double authentication. I really liked Phil’s point about shipping with maximum security first and then relaxing it based on real needs. I think this mindset should be a core strategy for new AI startups.

James Kaplan's avatar

There are a couple of interesting things here

- how do you ensure the cleanest possible code -- how do you use AI-enabled coding tools to drive security rather than insecurity

- how do you make UX choices that make the right tradeoffs given that business domain/value at stake?

Abdul Ahad's avatar

- There’s a need for revolutionary Agentic AI security checker, that can act as a red team for any startup, even for those who can’t afford the real red team.

- The tradeoff can only be found out through testing. Like phil mentioned at one place that they initially thought more people would turn of 2 factor authentication but they didn’t.

Heinz-Peter Sebregondi's avatar

First, we need to separate Cyber-security from the investment appraisal where you deal with investment-project-related risks.

Cyber-security falls into the CFO's Enterprise Risk Management Domain.

In dealing with risks, you have predictable/identifiable risks, and you have unidentified and unpredictable risks.

Risk response strategies are broadly: Avoid. Reduce and/or share. Accept.

More specifically:

Avoidance — Take action to avoid the risk, e.g. by clarifying requirements, acquiring

expertise, modifying scope, or changing the project plan.

Reducing risk — by applying targeted prevention measures such as reinforcing control processes, investing in additional protection, or upgrading workers’ technical skills.

Mitigation — Reduce the probability and/or impact of an adverse risk event to an acceptable threshold. Define actions to take when the risk occurs.

Sharing risks — e.g. joint ventures with partners.

Transfer — Have someone else handle the risk.

Insurance, warranties, guarantees, incentive/disincentive clauses, long-term contracts, etc., provided the price for the risk transfer can be supported by project cash flow. Risk transference nearly always involves payment of a risk premium to the party taking on the risk.

When two partners have two different valuations of a risk, one can sell it to the other.

Contracting strategy — Lump-sum turnkey (LSTK) contract based on an excellent project definition, when changes are unlikely, and where the contractor carries much of the project risks. In a high demand market, the risk premium can be high.

Acceptance — Identify the risk as acceptable and let it happen. The most common active acceptance strategy is to establish a contingency reserve, including amounts of time, money, or resources to handle the threat.

Investigate the risk that is not yet fully understood.

Heinz-Peter Sebregondi's avatar

Great insightful interview!

On "Historically, it’s been hard to get investment for underlying services over business functionality."

The problem of getting investment for underlying services, in my long observation, is a problem everywhere.

Engineers are just not educated how to determine the ROI of investments they deem necessary.

(A) Technical/operational employees often recognize many problems as well as the opportunities to solve the problems, for example, by improving processes and procedures or through automation.

But that always costs money, often a lot of money.

In my experience, they usually fail to prove the profitability of the recommended measures.

This refers to four aspects:

1) How an investment calculation is structured (Risk-adjusted Discounted Cash Flow Analysis, possibly with a probability distribution).

2) How to plan methodically (investment planning process — a stage-gate-process with decision gates).

3) How to get the data to feed into a calculation tool.

4) How to identify, quantify and manage risks — and prepare for unpredictable risks, the nasty surprises that always hit you.

On top of this: Since novelty and complexity are our main enemies in business, one needs to multiply initial estimates for cost and duration by 3 or 4, and reduce expectations for the outcome … it still can get worse. The Sydney Opera cost 14.6 times as much as originally planned.

Because they can't handle financial data themselves, the engineers are often frustrated and refer to the people from the finance department as "bean counters".

(B) MBAs have a hard time understanding business processes.

(That again allows McKinsey and others to preach the value of E2E business process optimization and automation.)

MBAs don't understand the underlying services.

So some important problems don’t get solved, unless there is some kind of crisis (e.g., leakage of customer data or increased waste in production) so that something MUST be done.

And — surprisingly — CEOs and CFOs are even not educated to care about bad revenue (e.g., excess product variety that leads to high average module costs and hurts competitiveness and profitability, or accepting lousy deals at the end of quarter or fiscal year to make stretch goals, or excessive discounts and hidden free services for Global Accounts with funding via overhead budgets, or allowing R&D to develop over-engineered products where revenues don’t cover the costs).

Who wonders then that they are blind re underlying services?

They do not see or know all layers of the full stack from businesses goals and strategy down to infrastructure.

But everything needs to be in sync.

The business schools have some blind spots.

James Kaplan's avatar

At some point we need to figure out how to unify the model i am building around tech ROI with the graph you drew about good versus bad revenue!

Heinz-Peter Sebregondi's avatar

After separating Cyber-security risks, we can look at the investment appraisal of a tech improvement/investment project:

Identify all related technical/operational value drivers such as man hours per process (process step) spent, depreciation of technical equipment etc.

Then relate these value drivers to the Financial ROIC value drivers:

Sales revenue,

Cost of goods sold (COGS), cost of sales, Materials,

Cost of goods sold (COGS), cost of sales, Manufacturing (in IT people related costs),

Selling expenses,

General & administrative expenses G&A,

Fixed assets (property, plant & equipment PPE, and

Working capital.

Then make reasonable estimates to quantify technical/operational and financial value drivers.

If, for instance, you need less assets in the future as a result of your investment, you need less debt and you have less interest to pay, which would provide a cash inflow in the investment calculation, and thus improve NPV, IRR, breakeven, etc.

So via the Financial ROIC value drivers, the technical/operational value drivers provide cash inflows and outflows for the investment appraisal.

And remember to also take care of the project related risks, which impact the final actual profitability of the investment at the end of its life cycle.

Heinz-Peter Sebregondi's avatar

IT costs might fall under G&A.

Heinz-Peter Sebregondi's avatar

Important to distinguish:

In Manufacturing, IT is a support function.

In some industries, IT is both a support function and a part of the value chain:

In Financial Services companies, IT provides the operational capability, the “factory”.

In Telecoms and IT service providers (e.g., IT infrastructure or software as a service), IT IS the business.

Heinz-Peter Sebregondi's avatar

Depreciation has various aspects: the useful life of an asset from a technical and from a tax perspective, the depreciation rate, ...

So you have both technical/operational and financial aspects.

Heinz-Peter Sebregondi's avatar

ROI is based on cash inflows and cash outflows over the life cycle of something, taking the cost of capital as discount rate into consideration.

When costs of a product or service are higher than revenues, you have negative cash flow, and the decision usually should be: get out of it.

There are a number of bad revenues, e.g.,

Orders, product lines, customers, brands, factories, stores, etc., where revenues do not cover their true actual costs. Be granular in your analysis and watch out for hidden costs.

Product variations whose prices do not cover the additional hidden complexity costs they cause.

Over-engineered, unnecessarily expensive products that do not earn their fair price.

Exceptionally huge discounts (quite usual at the end of quarter or fiscal year to make sales quota. Or to beat the competition: a computer vendor gave 80% discount on servers to a Global Account in order to keep a competitor out of the customer's sight — thus educating the customer to ask for extreme discounts in the future too.)

Crappy deals

* Outside customer value proposition (e.g. a best-cost commodity manufacturer who as an exception develops to order). [3 types of mutually exclusive customer value propositions of a business: Best (innovative) product, best cost of a commodity, best customized project.]

* High hidden costs to serve (funding via overhead budgets)

* Overly risky terms and conditions (e.g. turn-key lump-sum project TKLS, the supplier bears all risks) — quite usual for Engineering, Procurement and Construction (EPC) contractors when supply exceeds demand in the market place. They then depend on the customer having planned poorly, and thus on being able to achieve high margins with change orders.

Heinz-Peter Sebregondi's avatar

Correction: other measures of ROI exist too such as ROIC (return on invested capital), ROCE (return on capital employed), ROE (return on equity) or ROA (return on assets).

James Kaplan's avatar

How much it is engineers not able to communicate in terms of ROI and how much of is that the ROI is abstract?

“If we make this investment, business leaders will get functions they haven’t asked for yet in less time at less cost.”

Heinz-Peter Sebregondi's avatar

People who do not understand an investment appraisal cannot communicate ROI. ROI does not need to be abstract. I give my students an Excel calculation example of a Discounted Cash Flow Analysis for an investment including a simple guidance for determining the risk profile. Then they are easily able to work on a case based on a real Amazon warehouse expansion — with cash inflows and outflows (not the real ones) over 15 years. (A cruise ship needs to produce cash over 40 years.) When you have a novel project, you have huge uncertainty, and you might calculate different scenarios, and since you can only plan what you know, and because by definition much or most of the project is unknown, making it in reality an R&D project, you might have to multiply initial estimates by 3 or 4. In large projects, you create a risk register with respective estimated impacts and probabilities, you do a Monte Carlo simulation, and you get probability distributions for Net Present Value NPV, Internal Rate of Return IRR, Total Installed Cost TIC, Duration, etc. Then there is still the question how to determine cash inflows and outflows. People would make estimates, and the best they can do is get guidance and support from people in the company who have a great reputation and credibility — but with a novel project, they too can be totally wrong.

User's avatar
Comment removed
Jan 15
Comment removed
James Kaplan's avatar

But the defenders have to increase their transparency into their environments quickly!