Risk Management

Companies rarely fail for novel reasons. The customer that supplied half of revenue leaves, the one engineer who built the billing system resigns, customer data gets out, or a rule changes and makes the current approach illegal. All four give off signals long before they land, and in most cases somebody inside already knew. What was missing was a place to write it down and decide who would do what by when.

Without that place, a company only moves after the fact. And after the fact there is very little left to choose from. Start looking for replacement customers on the day your largest account gives notice, and in a market where one contract takes eight months you are already late. Start mapping what someone built on the day they resign, and the handover comes down to a few links and whatever they happen to remember. The difference between handling something early and handling it late is not diligence — it is the number of options still on the table. That number only shrinks. Something that six months earlier would have been solved by adding one person becomes, on the day it lands, a problem that stops other work and still might not be solved.

Pagedeck got its own scare. At 45 people, its largest customer said it would not renew the following year. That single account was 23 percent of annual revenue. When Grace asked what the plan was, Sofia said building a list of prospects at a comparable size would take weeks on its own, and Ravi said he had never run ads that reached companies of that size. Working the numbers afterward showed the top three customers were 47 percent of revenue — a figure that had been sitting in a monthly report for two years. Nobody had read that line as a risk. The report was not wrong and nobody had hidden anything; the number was simply printed next to twenty others, with no column saying what it would mean if that share kept climbing.

Risk management turns that reading into a routine. Write down what could plausibly go wrong, weigh each one by how likely it is and how large the damage would be, rank them, and attach preparation starting from the top. Using both axes together is the whole mechanism. A data breach might happen once in several years, but it can end the company, so it sits near the top; a two-hour outage happens most quarters and is recovered by the next day, so it sits lower. Judge by likelihood alone and the breach falls to the bottom of the list. Judge by damage alone and everything looks urgent, which makes choosing impossible.

The terms under this name fall into two branches: naming what the risks are (types) and deciding what to have ready for them (preparation). The first builds the list; the second answers the rows at the top of it.

Types are names given in advance to the risks that keep recurring. Having a name means the item doesn't get skipped, and it means you can look up how other companies handled the same thing. Four are common.

1. Customer concentration risk — revenue leaning on a small number of accounts. One account above 10 percent of the total, or the top five above half, is usually read as a signal. The danger is not only that the customer might leave. Even while they stay, negotiations run from a position where saying no is not realistic, so price cuts and one-off features built for that account get accepted.
2. Key person risk — an organization that stalls when one specific individual is unavailable. It appears wherever one person is the only one who knows a procedure or holds an access credential. It isn't a problem with that person; it's what happens when something built in a hurry stays the way it was built, which is why the fix is writing it down and splitting it between two people.
3. Regulatory risk — laws or rules changing in a way that blocks the current approach or makes it more expensive. Where personal data may be stored and how payment details must be handled are the usual examples. Compliance rarely starts on the day the rule takes effect, since most changes need months of preparation, so the watching starts when the change is first proposed.
4. Reputational risk — losing enough trust that both selling and hiring get harder. It's often produced by the response rather than the incident. Two companies can have the same outage, and the one that explained what happened and what was fixed the same day gets treated differently in the next renewal than the one that posted three lines three days later.

Preparation is what actually gets attached to the rows that reach the top. It splits in two, according to whether it is capability you maintain all the time or a plan you write for one specific situation.

1. Business continuity — the setup that keeps the business running when something goes wrong. Losing the office, losing a data center, or losing half the staff to illness at once should still leave the essential functions working. Two numbers get decided here: how many hours until service is restored, and how many minutes of data you can afford to lose. Once those exist, how often to back up and how much standby infrastructure to keep follow from them.
2. Contingency plan — the alternative plan for one particular thing going wrong. If business continuity is general fitness, this is a scenario script. What gets cut and what gets protected if the largest customer doesn't renew; how many months of cash carry the company if a funding round slips. What decides whether it's useful is the trigger. Writing it as a number — the day a top account signals no intent to renew, or the day remaining cash drops below nine months — is what lets the plan switch on without a meeting first.

The two branches meet on one table. Types supply the rows, each row gets a likelihood and a damage score that produce an order, and only the upper rows get preparation attached. Lower rows are not deleted; they stay and get reread at the next review, because the order changes. The top row at 45 people is not the top row at 200. At 45, losing one engineer can stop a release; at 200, the same departure is absorbed, while a rule change that was irrelevant at 45 now touches thousands of customer records. Rereading the lower rows is how the list keeps up with the company rather than describing the company it used to be.

Scoring varies by company, but most give each axis a 1-to-5 value and multiply. A data breach at likelihood 2 and damage 5 scores 10; a half-day outage at likelihood 4 and damage 2 scores 8; losing a top account at likelihood 3 and damage 5 scores 15. The numbers are not precise, and precision isn't where the value is. When two people score the same row differently, they end up explaining why they see it differently, and that is usually when a fact one of them didn't have comes out.

"This one is unlikely but it ends the company. Let's not rank it by probability."

An argument for reading the damage axis first, and against burying something at the bottom of the list just because it's rare.

"If the top three customers are half of revenue, it will come up in the next round of due diligence."

Customer concentration isn't an internal worry — it's an item that gets priced in when outsiders value the company.

"Nobody besides Theo knows that deploy procedure yet. Let's get a second person on it this quarter."

Converting key person risk from a concern into a task with an owner and a deadline.

After nearly losing its largest account, Pagedeck set aside one hour each quarter. Grace puts the table on screen and each team reads its own rows. The first version had 23 rows; after scoring and sorting, only the top five got an owner and a date. The other eighteen weren't deleted, just marked for the next review.

Three of the five actually moved that year. Sofia brought the top three accounts down from 47 percent of revenue to 35 over twelve months, the deploy procedure only Theo knew was documented and split between two people, and the way customer data is handled went through an external review. The fourth row, a regulatory change, produced nothing at all that year, and Grace didn't count that as wasted effort: because it was on the list, the week the change was announced the team already knew what to check.

This meeting is not the same as incident management. Incident management opens when the service is down right now; this one opens in a quiet quarter when nothing is happening. That's exactly why it gets postponed — it's the meeting with nothing urgent in it.

The most common reading is that keeping a risk list is a habit of timid companies, and that worrying about things that haven't happened is a poor use of a period when speed matters. But the output isn't a company with no risks; it's a company that has decided which risks it is carrying knowingly. A team can decide to leave a top account at 30 percent of revenue. What that team then does is put the renewal date on the calendar, hold more cash going into that month, and keep a list of replacement prospects ready. The difference between carrying a risk and carrying it knowingly sits right there. A company without a list is not a company without risk — it's one that doesn't know which risks it holds. The sense that this work slows things down usually has the order backwards, too: a team that has decided what it's carrying moves past that item without reopening it, while a team that hasn't has the same worry surface in meeting after meeting and starts the discussion over each time.

The second misreading is that having the list means the risk is managed. A document feels like a finished task, and investors and enterprise security reviews ask to see one, which reinforces it. But unless every row carries an owner, a deadline and a next review date, the only thing that changes each quarter is the date at the top. Pagedeck assigned owners to five rows rather than all 23 for exactly this reason: put a name on everything and nobody treats any of it as theirs. A list that grows without anything being done has a second effect as well. A document where everything is marked as a risk points at nothing, and the row that genuinely belongs at the top reads with the same weight as the twentieth line.