TL;DR: On April 15, NIST announced that the NVD will stop enriching most CVEs. The industry is framing it as a crisis. It isn’t. Three of the four enrichment fields — CVSS, CWE, reference tags — were already duplicated by the CNAs and vendors closest to the vulnerability, or trivially automatable by anyone willing to do the work. Only CPE mattered, and CPE was already being replaced by PURL in every ecosystem with a package manager. What NIST actually did was end a subsidy that was distorting incentives: the NVD carried work that should have been done by whoever knew the product best. Now that work has to come from the CNAs, the vendors, and the consumers themselves. Each actor in the chain finally has skin in the game. That is a healthier pipeline than what we had.

On April 15, 2026, NIST announced that it was giving up on enriching most CVEs. My Slack lit up with the panic you’d expect from a community whose tooling sits on top of vulnerability data. The framing was apocalyptic everywhere: the backbone of vulnerability management is breaking, the CVE ecosystem is collapsing, the public good is on life support.

I’m a Research CNA. I’ve spent the last few years watching how vulnerability data actually gets produced, packaged, and consumed — upstream as a participant (assigning CVEs for vulnerabilities my team finds) and downstream as a vendor (our product ingests CVE data at scale). When the announcement hit, I didn’t open a press release. I opened our own ingestion pipeline and asked a blunt question: how much of what we actually use comes from NIST’s enrichment, and how much of it would we miss if it disappeared tomorrow?

The answer surprised me, and then it didn’t. Most of what people are mourning was already duplicated elsewhere by the actors who actually knew the vulnerability best. One thing was not. And that one thing is about to be obsolete for a reason that has nothing to do with the NVD.

This is a post about that audit. It is also a pushback against a narrative I think is wrong — or, more precisely, wrong in its weight. The NVD’s capitulation is not a catastrophe. It is the overdue retirement of a subsidy that was distorting incentives across the vulnerability supply chain. For two decades NIST was doing work that belonged, by any reasonable division of labor, to someone else. The panic is loudest among the vendors who happen to sell the replacement. That alone should make you suspicious.

What the Notary Actually Did

Think of NVD enrichment as notarization. When a CVE is submitted by a CNA — MITRE, a vendor, a research team like mine — what arrives in the database is a description, a list of reference URLs, and maybe a CVSS score if the CNA bothered to assign one. A NIST analyst then applies four stamps to convert that raw record into something operationally useful:

• CVSS stamp — a severity score computed under uniform NIST criteria.

• CWE stamp — the category of the underlying weakness (is this a SQLi, an XSS, a memory corruption, a misconfiguration?).

• Reference-tag stamp — labels on the URLs: this one is a patch, this one is an exploit, this one is a vendor advisory.

• CPE stamp — the machine-readable mapping that says this CVE affects product X, versions 3.0 through 3.4, running on platform Y.

That’s it. Four stamps. The entire industry has been treating them as a single sacred bundle. They are not. They are four very different things with four very different replacement costs, and the panic narrative conflates them. Let’s take them one at a time.

Three Stamps Nobody Will Miss

The CVSS stamp was already duplicated. When NIST says it will stop assigning its own score when the CNA already provided one, it is quietly admitting what the industry has known for years: most major CNAs now publish CVSS at disclosure. Microsoft, Cisco, Red Hat, Oracle, GitHub Security Advisory database — all of them have been scoring their own vulnerabilities for over a decade. Is the quality uneven? Yes. Is the NIST analyst’s score systematically better than the CNA’s? Not really — it is often the same number rederived by someone with less context about the vulnerability than the engineer who wrote the patch. What NIST provided was the illusion of a neutral arbiter. That illusion was always thin. Losing it changes the discourse around disputed scores, but it does not create a data void. The data was never exclusively NIST’s to begin with.

The CWE stamp is inferable. CWE classification is a bounded categorization problem. There are a few hundred CWE entries, the vast majority of disclosed vulnerabilities map to a short list of common ones (CWE-79, CWE-89, CWE-287, CWE-416, a handful more), and the mapping can be derived from the vulnerability description with high accuracy. I know this because we do it. A modern LLM fed a CVE description can assign a plausible CWE with better-than-human consistency — not because the model is smarter than a NIST analyst, but because the problem has a small, well-defined output space and the input is structured prose. If CWE classification is your operational bottleneck in 2026, the problem is not that NIST stopped enriching; the problem is that you haven’t automated what has been automatable for two years.

The reference-tag stamp is nice, not critical. Labeling URLs as Patch versus Exploit versus Vendor Advisory is useful. It is not foundational. Most tooling that cares about reference tagging already does its own classification with URL patterns, domain reputation, and lightweight content inspection — because NIST’s tagging was always partial and inconsistent anyway. I will miss it at the margin. I will not rebuild my stack because it is gone.

Three of the four stamps. Duplicated, inferable, and marginal, respectively. If these were everything the NVD did, the April announcement would be a non-event.

The One Stamp That Actually Mattered

The CPE stamp is different.

CPE — Common Platform Enumeration — is the layer that says this CVE applies to cpe:2.3:a:apache:log4j:2.14.0:*:*:*:*:*:*:*, to all versions between 2.0 and 2.14.1, excluding versions X and Y. It is the mapping that makes automated vulnerability scanning possible. A scanner walks your software inventory, builds a list of CPEs, matches against the NVD’s CPE expressions, and produces the list of CVEs you are actually exposed to.

Without CPE, a CVE is text. With CPE, a CVE is data.

This is the stamp whose loss is real, and here the replacement cost is genuinely high, for three reasons. CPE mapping requires product knowledge the CNA does not always have in structured form. A vendor advisory says “affects versions 3.0 through 3.4.” Converting that into a CPE expression with precise ranges, correct vendor and product normalization, and the right platform conditions is skilled, tedious work. The skill is unglamorous; it is lexicographic discipline. The CPE dictionary itself is degrading. Without enrichment, new products do not get CPE entries. The vocabulary shrinks relative to the ecosystem. The problem compounds. Scanners that match by CPE become blind to unenriched CVEs. Not wrong, not delayed — blind. The CVE exists in the NVD, but from the scanner’s point of view it does not apply to anything.

If the story ended here, the panic would be justified. It does not end here, because the world did not stop in 2010 when CPE was the only game in town.

The PURL Pivot

CPE was designed in the era when “software” meant commercial products with vendor names, fixed releases, and stable identifiers. Microsoft Windows 10 version 1903. Apache HTTP Server 2.4.41. Oracle Database 19c. The vocabulary assumed a small, identifiable set of entities, each one curated by a human analyst into a central dictionary.

That world died sometime between the rise of npm and the normalization of containerized deployments. Modern software is a graph of open-source dependencies, each one published to a package registry with its own naming conventions and release cadence. The correct identifier for a given piece of code is no longer “Apache Log4j 2.14.0” — it is pkg:maven/org.apache.logging.log4j/log4j-core@2.14.0. That string is a PURL, a Package URL, and it has a property CPE never had: it is generated at the source by the package manager itself.

PURLs do not need an analyst to curate them. They are machine-readable by construction. They are embedded natively in every modern SBOM format — CycloneDX, SPDX — and they are already how the Open Source Vulnerabilities database (OSV) and the GitHub Advisory Database identify affected packages. When you run npm audit, pip-audit, or Trivy against a container, you are matching by PURL, not by CPE, whether or not you realized it.

The NVD’s CPE monopoly was not ending because NIST gave up. It was ending because the center of gravity of modern software moved to ecosystems where PURL is native and CPE is a retrofit. NIST’s April announcement is a trailing indicator, not a leading one. The funeral is for a dictionary that was already becoming a museum piece.

Where LLMs Close the Gap

A real gap remains, and it is the one PURL does not fix on its own: the long tail of commercial, proprietary, and firmware software where no package manager exists. Routers, industrial control systems, enterprise SaaS, medical devices, point-of-sale terminals. For that tail, CPE was never great — but it was something, and when NIST stops providing it, there is nothing obvious to replace it with.

This is where LLMs are not a silver bullet, but a very sharp tool. A language model fed a CVE description, the referenced advisory, and a product catalog can produce a plausible CPE or PURL-equivalent mapping with accuracy that is not yet at the level of a disciplined human analyst, but is already higher than the accuracy of an overworked analyst processing 50,000 CVEs a year. More importantly, the inference is reproducible, auditable, and scales with compute rather than with headcount.

The honest framing is this. For the open-source half of the ecosystem, PURL replaces CPE natively and the NVD was never the real bottleneck. For the commercial long tail, LLM-assisted inference replaces what NIST analysts were doing with a process that is measurably imperfect but operationally viable. Between the two, most of what matters gets covered. The remaining gap is real, but it is shrinking — and it is shrinking in the direction where tooling improves faster than bureaucracies do.

Skin in the Game

The NVD enrichment collapse is being narrated as an ecosystem crisis. Read carefully, it is the opposite: a forcing function that is accelerating a transition the ecosystem was already halfway through, and a correction of incentives that had been misaligned for two decades. Three of the four NVD stamps were already being duplicated or were trivially automatable. The fourth — CPE — was the last residue of a centralized, dictionary-based, human-curated model that package ecosystems and SBOM standards had quietly been replacing for five years.

The deeper point is about who should be doing the work. For most of the NVD’s history, a federal agency with no commercial relationship to the software it catalogued was curating the metadata for the entire industry, for free. That is a subsidy, and subsidies distort. Vendors had no operational reason to publish structured CVSS, CWE, or CPE data at disclosure, because NIST would do it for them. CNAs could ship half-finished records because the NVD would fill in the gaps. Consumers treated the NVD as ground truth because it was the only source with a uniform format. None of these actors had any skin in the game. The work of making a CVE operationally useful was outsourced to an overworked public-sector team that, predictably, eventually broke.

What is emerging now is messier, but it is more honest. CNAs are under pressure to enrich their own disclosures, because there is no longer a backstop. Vendors have a reason to publish PURLs for their open-source components, because that is what SBOM pipelines consume. Consumers have to think harder about what sources they trust and why, because there is no single authoritative feed anymore. Each actor has to do the piece of the job they are actually best positioned to do. That is not a crisis of vulnerability management. That is vulnerability management growing up.

If you run a program and your only response to the April announcement is to panic and subscribe to a commercial enrichment feed, you are paying someone else to maintain the old subsidy on your behalf. That is fine as a stopgap. It is a bad long-term strategy. The better move is to rebuild your pipeline around PURL-native data for everything that has a package manager, LLM-assisted inference for everything that does not, and direct relationships with the CNAs whose products actually run in your environment.

The NVD was not the backbone of vulnerability management. It was the scaffolding — the thing that held the ecosystem up while the real infrastructure got built. The scaffolding is coming down, and what was underneath is a pipeline where everyone finally has to pay attention to their own work. That is not a crisis. That is progress.

TL;DR: The AppSec industry treats “prioritize and forget” as mature judgment when it is actually an artifact of manual remediation being expensive. This article argues three things: that the logarithmic ROI curve is a lie the industry tells itself to avoid industrializing remediation; that the real cost of a fix is not four hours of engineering but the risk-acceptance ceremony that legalizes not doing it, which is more expensive; and that the tail of mediums and lows is where attacker chains live, so cherry-picking criticals is structurally insufficient. The practical conclusion: stop deciding what to leave broken and start building the preconditions — unified backlog, precise detection, micro-changes, reversible deploys — that make remediating everything cheap.

A few weeks ago I was on a call with the CISO of a mid-sized SaaS company. Smart guy, ten years in the industry, decent budget. His team had just closed a quarterly cycle: 3,847 open vulnerabilities. Eleven criticals. Sixty-four highs. The rest — the vast, humid rest — were mediums and lows that had been accumulating for years like sediment at the bottom of a reservoir.

His question was the one I have heard hundreds of times in fifteen years of application security:

“Which ones should we fix?”

I want to dedicate this article to destroying that question. Not the CISO — the question itself. Because that question, which sounds so reasonable and grown-up, is the polite face of a practice that is structurally wrong and economically regressive. The honest answer is: all of them. Deliberately, as part of your normal engineering cadence, forever, like brushing your teeth. If your first reaction is that this is economically insane, we have already identified the disease.

The logarithmic lie

There is a graph in every vendor pitch deck. X axis: vulnerabilities remediated. Y axis: risk reduced. Curve logarithmic — steep at the beginning, flat at the tail. The takeaway is always the same: focus on the critical few, ignore the trivial many, that’s where the ROI lives.

I call this the logarithmic lie. Not because the math is wrong, but because the assumption that makes the math work is buried so deep almost nobody sees it.

The assumption is this: the cost of remediating each vulnerability is constant and high. That one assumption bends the curve. If remediation is expensive, yes, marginal fixes near the tail don’t pay for themselves. Prioritize, forget, go home.

But what if a fix is not a multi-week project? What if it is a micro-change — a dependency bump, a header added, an input sanitized — generated by an agent in ninety seconds, reviewed in thirty, merged behind a feature flag, deployed to one percent of traffic, reverted automatically if any signal degrades? The worst case is seconds of partial degradation for a small traffic slice, caught by the canary before anyone notices.

What does the logarithmic curve look like when each point costs three minutes of machine time and rollback is cheaper than the fix? It looks like a line. A slightly noisy line sloping gently upward, where every fix costs almost nothing. On that line, the ROI argument collapses. The reason you wouldn’t remediate finding number 3,000 stops being “diminishing returns” and becomes something simpler: you haven’t industrialized the work.

The Detroit problem, the aviation answer

Remediation is expensive because nobody remediates at scale, and nobody remediates at scale because remediation is expensive. A Nash equilibrium, and a particularly stupid one.

A senior engineer in Colombia at $15M COP/month costs closer to $23M once you count benefits and fiscal carry. When a finding from SAST, AI-SAST, SCA, Secret Scanning, or DAST lands in this organization, it sits in a queue because nobody owns it. When someone looks, they triage five findings to fix one real bug because false positive rates run 15-20%. The PR waits for review. CI takes 45 minutes. The deploy hides behind a forgotten feature flag. Four to six hours of engineer time per fix, across three people, two weeks of wall-clock. Call it $800K COP. Multiply by 3,000 mediums: $2400M COP no CFO will sign.

Except that is not the real comparison. The real comparison is four hours of engineer time versus the cost of deciding not to do it. That second column never appears in the board deck. It looks like this: three meetings of one hour with four people each — score the finding, debate exploitability, document compensating controls, sign off a formal risk acceptance. Two of the four are VPs whose fully-loaded cost is five times the programmer’s. Twelve person-hours to produce a PDF in a GRC tool saying we have legally decided not to fix this thing. No defense added. No attack surface reduced. Meanwhile the programmer who could have added a defense-in-depth input validation in thirty minutes was not invited. That would have been unprofessional.

I cannot say this politely. The AppSec industry has built an enormous, well-compensated apparatus whose function is to legalize not fixing vulnerabilities, and it is more expensive than fixing them. The ceremony of risk acceptance is the modern rework bay: a room full of salaried people managing the consequences of not doing the thing that, industrialized, would cost almost nothing.

Detroit made this mistake in the 1970s; Toyota proved them wrong over thirty years. But the model I want you to sit with is aviation. Commercial aircraft operate under continuous, legally-mandated long-tail maintenance — A-checks every 500 flight hours, D-checks every 6-10 years where they disassemble the plane. When any operator anywhere reports a defect, airworthiness directives force every aircraft of that model to inspect it. There is no triage meeting. You check it, fix it, log it, fly. The reason this works — the reason Bogotá-Madrid costs USD 800 on an aircraft carrying hundreds of millions of dollars of cumulative maintenance — is that aviation spent seventy years engineering the preconditions that make each event cheap: modular components, standardized tooling, exhaustive documentation, trained mechanics at every airport. Enormous cost paid once, amortized across every flight on earth.

AppSec has not paid that cost. And so we live in a world where “medium severity, low exploitability, deprioritize” passes for professional judgment, when the aviation equivalent — “slight hairline crack, low probability of structural failure, let’s skip it” — would end a career.

The backlog is one backlog

One point sabotages most organizations before they start. Security work does not live in a separate backlog. The moment you create “the security backlog” distinct from “the engineering backlog,” you have lost. Work parked there gets “when we have time” priority, which means never.

Remediation has to be feature work for the team that owns the code. Same backlog, same review standards, same Definition of Done. A dependency bump for a transitive CVE is a ticket in the same Jira project as the new checkout flow. The security team does not hand off work — it supplies validated, deduplicated findings into a system engineering already operates. Aviation does not have a separate “safety backlog” negotiated against flight operations. Safety is maintenance. Maintenance is operations. One system, one queue.

The preconditions we refuse to build

Every time I argue for remediate-everything, someone raises a valid objection. These objections are real, and every one describes a precondition the industry has chosen not to build:

• “Our scanners are too noisy.” Fine. Industrialize scanner accuracy. Combine SAST, AI-SAST, SCA, Secret Scanning, and DAST with reachability analysis. Validate with humans. Drop false positives below 5%. This is not science fiction — some vendors already do it today.

• “We’d destroy our CI throughput.” Fine. Industrialize the pipeline. Parallel builds. Aggressive caching. Feature flags. Canary deploys. These are 2015 technologies, not 2035 speculation.

• “We don’t know who owns what code.” Fine. Industrialize ownership. CODEOWNERS files are free. Architectural decision records are free. “We don’t know who owns this” is a choice, not a condition.

• “Fixing things breaks things.” Fine. Industrialize your test coverage and your rollback. If your fix is a micro-change behind a feature flag with a canary that auto-reverts on error-rate regression, the blast radius of a bad fix is seconds of partial degradation for a small traffic slice. That is not the same category of risk as a two-hour outage. Treating them as equivalent is how you justify the status quo.

Every one is an argument for building the preconditions, not for refusing to remediate. A hospital that said “we can’t afford to sterilize all the instruments” would be closed within a week. We accept the equivalent argument in AppSec because we grew up inside it.

The honest name for this refusal is laziness — organizational laziness. It is more comfortable to have the same “we have to prioritize” meeting every quarter than to do the multi-year work of building the system that makes the meeting obsolete. The meeting produces slides. The system produces nothing visible for two years, then suddenly produces a company that fixes any vulnerability in hours and ships through it without blinking. Guess which one gets funded.

The tail is where the attackers live

The logarithmic curve measures individually attributable risk. At the tail, the honest answer is “very little” — in isolation. Real attacks are never in isolation. Real attacks are chains.

SolarWinds was a) a compromised build pipeline, plus b) a legitimate signing certificate, plus c) a dormant backdoor with a 12-day incubation, plus d) weak segmentation across 18,000 downstream organizations, plus e) EDR evasion. Equifax was a) an unpatched Struts CVE with a fix already available, plus b) an expired TLS certificate that silenced monitoring for nineteen months, plus c) a flat network exposing 48 databases. Target was a) a stolen HVAC contractor credential, plus b) an exposed vendor portal, plus c) lateral movement, plus d) POS malware, plus e) an unmonitored FTP exfiltration path.

None were caused by a vulnerability labeled “critical” in isolation. Every one was an alignment of mediums and lows that, individually, any CISO under the logarithmic doctrine would have deprioritized — and, quite plausibly, did. James Reason called this the Swiss cheese model: layers of defense each have holes, accidents happen when the holes line up. You cannot predict which will align. The only robust defense is reducing the total count of holes across all layers — a population strategy, fundamentally incompatible with cherry-picking criticals.

Other high-stakes industries are decades ahead on one more thing. In aviation, when something almost goes wrong, pilots report to the Aviation Safety Reporting System, run by NASA at arm’s length from the FAA so career consequences don’t chill reporting. Anonymized, aggregated, published. A near miss in Seattle becomes a training bulletin in Singapore next month. Banks share fraud signals the same way: a scam hitting one bank at 2 AM reaches the others by end of business.

Security does none of this. An incident has to be regulated into disclosure — SEC 4-day rules, GDPR notifications — and what gets shared is the sanitized post-mortem of an actual breach, months late, written by lawyers minimizing liability. The near miss — the attempted intrusion that failed, the misconfiguration caught before exploitation — sits in an internal Jira labeled “not exploited, closed,” and that is the end of its epistemological life. Every company is its own first victim of every attack pattern.

If you cannot learn from other organizations’ near misses, you have to assume any finding in your environment, however mundane, could be the first link in a chain someone else has already seen but cannot tell you about. Under those conditions, remediating everything is not paranoia — it is the only epistemically defensible strategy.

The detection paradox, the factory ahead

An uncomfortable observation about the industry I make my living in. The last five years have been a gold rush of detection — AI-SAST with semantic context, reachability analysis, SCA tracing transitive dependencies, secret scanners correlating git history, DAST exercising real auth flows, exploitability engines chaining findings. Real progress. The most significant advance in security tooling since the invention of the scanner.

And it has produced almost no improvement in the rate at which vulnerabilities actually get fixed.

Here is the paradox: if detection is precise and exploitability analysis is accurate, the two necessary inputs to an autonomous patcher are already in place. A precisely located flaw, with a precisely understood attack path, in a precisely bounded region of code is a fully-specified input for a remediation agent. The fact that the industry invested so heavily in knowing exactly what is wrong, where, and how it would be exploited — and has not closed the loop to therefore, here is the patch — is not a technical limitation. It is a failure of imagination.

Every piece exists in fragments. Precise detection. Exploitability analysis. Autonomous coding agents. Elastic CI. Feature flags. Canary deploys. Auto-rollback. Unified backlogs. The pieces are on the shelf. Assembling them is hard engineering work, but it is not research — it is assembly. Someone will assemble it. The question is whether that happens inside the current AppSec industry or to it.

If you are running security today, the question on your desk is not “which of my 3,847 findings matter most.” It is: how do I get my organization to the point where that question is no longer interesting? How do I unify the backlog, shrink the fix into a micro-change, build the rollback safety net, get detection precise enough and the pipeline fast enough that the answer to every finding is simply “yes, and it’s already in progress”?

The answer to “which ones should we fix” is all of them. What you should be asking is what stops me from fixing all of them? — and kill those obstacles one by one, with the seriousness you would bring to a production outage. Every obstacle is a decision to run a workshop instead of a factory. To stay in 1975. To keep having the meeting.

Toyota took thirty years. Aviation took seventy. AppSec will probably take a decade, and most organizations will not make it. The ones that move first will build structural advantage nobody catches up to.

Prioritize the order. Remediate everything. Build the factory.

TL;DR: The cybersecurity industry has been reading the CVE count as if it were a passive thermometer of risk, when in fact it is a reflexive instrument — one that catalogs vulnerabilities and, for the subset that gets weaponized, materially causes the exploitation it is meant to prevent, with a measured lag of five hours. This article argues three things: that most of the CVE growth since 2021 is administrative catch-up concentrated in five CNAs and specific ecosystems (WordPress, Linux kernel, OSS); that the metric has become structurally reflexive in the Soros sense, with the added pathology that its costs are externalized to defenders who had no voice in the disclosure; and that better metrics exist (exploitation pressure, weaponization velocity, defensive friction) but nobody publishes them continuously. The practical conclusion: stop anchoring policy, insurance, and strategy to a number that burns what it measures, and start building the dashboard that would replace it.

Every January, someone writes a headline about how cybersecurity got worse last year. The evidence is always the same number: the count of published CVEs grew by 38%, or 21%, or some other double-digit figure. The industry repeats it. Regulators cite it in policy memos. CISOs use it to justify budget requests. Vendors weave it into sales decks.

The number is real. The interpretation is not.

The deeper problem this article tries to address is that the world has been making cybersecurity decisions — budget allocations, regulatory thresholds, insurance pricing, incident disclosures — anchored to a single indicator that does not work the way people assume it works. For twenty-six years we have treated the CVE count as if it were a thermometer taking the temperature of a stable outside world. It is not that. It is an instrument that catalogs vulnerabilities and, for a meaningful subset of them, also causes the exploitation it is trying to prevent — with a measurable lag of about five hours.

If that sentence sounds like hyperbole, stay with me. By the end of this article I want you to have in your head three ideas: what the five hours means, why the rest of the metric is mixed in a way that nobody is disentangling, and what we would measure instead if we were serious about fixing this.

The lighthouse analogy

Imagine a lighthouse built to help ships navigate a dangerous coast. The beam is broadcast to every ship within range. Ships that see the beam and know how to read it — professionally captained, well-staffed, with updated charts — avoid the rocks. That is the point of the lighthouse.

But the beam is also visible from the land. And over the years, as the coast has grown more trafficked, a class of people has set up on the cliffs to watch the beam for different reasons. They use it to identify which ships are in which position, to time their predations against ships whose captains are distracted or whose crews are short-handed. The lighthouse was designed to help sailors. For a specific subset of watchers, it has become operational intelligence for the things the lighthouse was meant to warn against.

You cannot turn the lighthouse off. Without the beam, the ships that depend on it crash. You cannot make the beam selective — physics does not let you send photons only to friendly eyes. The lighthouse is simultaneously the best defensive tool available and a non-zero contribution to the risk it was built to mitigate. The ratio between the two effects depends on who is sailing, who is watching, and how fast each side can act on what they see.

That is the CVE program. A public catalog with descriptions, affected versions, and often links to proof-of-concept exploits is exactly what a defender needs to scan their own systems. It is also exactly what an attacker needs to scan everybody else’s. The two uses of the same information have been in rough balance for most of the program’s history. Recently, for a specific subset of the catalog, the balance has shifted in a direction that the topline number cannot show.

Five hours

Here is the fact that should be quoted every time someone writes a headline about CVE volume.

Patchstack’s 2026 State of WordPress Security report contains this sentence: the weighted median time from public disclosure to first mass exploitation of a WordPress plugin vulnerability is five hours.

Not five days. Five hours.

The same report documents that 52% of plugin developers do not ship a patch before the disclosure window closes. The coordinated disclosure process runs its standard timeline, the researcher gives the vendor 30 or 90 days, the CVE goes public — and more than half the time, the vulnerable version is still the only version available when the scanners start.

So the operational reality of a critical CVE in a popular ecosystem looks like this:

• Hour 0: the CVE is published with description, affected versions, sometimes a PoC.

• Hour 1 to 3: Nuclei template authors and Metasploit module maintainers integrate it. Shodan queries and Censys saved searches get updated.

• Hour 5: median first mass-exploitation attempt against unpatched installations.

• Hour 48 to 72: if the vendor was in the 48% who shipped a patch on time, auto-updating customers start being safe.

• Day 30 and beyond: the long tail of unpatched installations continues being exploited. Qualys’s analysis of one billion remediation records puts the average window of exposure at 85 days.

For the subset of CVEs that get weaponized, the public disclosure is the starting gun of a race that was not running before it fired.

I am not claiming every CVE has this property. VulnCheck’s analysis of a decade of data shows that only about 1.1% of published vulnerabilities are ever observed being exploited. Most of the catalog sits there, quietly, never weaponized. The lighthouse beam mostly helps sailors. The problem is that within the WordPress ecosystem, Patchstack reports 41% of H1 2025 vulnerabilities are “exploitable in real-life attacks” — and the WordPress ecosystem has grown to account for a significant share of the entire CVE catalog. The reflexive effect is concentrated, but the concentration is in the part of the catalog that has been growing fastest.

Reflexivity, and why this is not a normal measurement problem

There is a useful name for what is happening here, borrowed from a field where it has been studied for forty years: reflexivity.

The concept comes from George Soros, who built one of the most successful hedge funds in history partly by betting against the assumption that market prices passively reflect underlying fundamentals. His argument, developed across several books, is that prices and fundamentals form a feedback loop. Market participants observe prices, form beliefs about what assets are worth, and act on those beliefs — buying, selling, extending credit, hiring, investing. Those actions then change the underlying fundamentals that the prices were supposed to be measuring. A stock price that rises on optimism lets the company issue cheaper debt, hire more, expand faster, which then validates the higher price with fundamentals that the price itself helped create. The measurement modifies what is being measured. The loop runs until the gap between perception and reality becomes too large to sustain, and the whole thing corrects violently.

Soros’s point was not that markets are irrational. It was that markets are a particular kind of system — one where the observer and the observed are not separable — and that treating them as if they were a thermometer reading an independent reality produces the wrong conclusions. Traders who understand this, he argued, have a better model of what is happening than economists who assume efficient-market conditions.

The CVE program has the same structure. The cognitive function of the program is to describe the state of software security — what vulnerabilities exist, where, in what versions. The manipulative function, in Soros’s language, is what the disclosures do to that state once published: they change attacker behavior, defender behavior, economic incentives for researchers, the calculus of what is worth weaponizing. The two functions are not separate. Every CVE is simultaneously a description of a state of the world and an intervention into it. The industry has been reading the CVE count as if only the cognitive function existed.

There is one important place where the analogy to financial reflexivity breaks down, and it is worth naming. In markets, when the loop produces bad outcomes — a bubble bursts, a price corrects — the pain falls on the participants in proportion to their exposure. People who bought at the top lose the most. The feedback loop that creates the distortion is the same loop that punishes the participants who caused it. Markets are self-correcting, eventually, because the costs land on the decision-makers.

In the CVE ecosystem, the costs do not land on the decision-makers. When a disclosure creates a five-hour window during which unpatched systems get mass-exploited, the pain falls on the site owners running the vulnerable software, whose vendors did not ship a patch in time, and who had no voice in the disclosure decision. The CNA that published the CVE bears no cost. Its business model is, in fact, reinforced — every disclosure that produces exploitation is evidence that its work matters and generates demand for its products and services. The feedback loop that would normally self-correct a reflexive regime — decision-makers paying for their own bad calls — is broken here. The reflexivity is not just present; it is reflexivity with externalized costs, which is a worse configuration than anything Soros was describing in finance.

This is why “just fix the measurement” is not a sufficient answer. The problem is not that the CVE count is mismeasured. The problem is that the entire system — catalog, CNAs, disclosure norms, consumer tooling, regulatory frameworks — has been designed around the assumption that the catalog is a passive description of an independent reality, when in fact the catalog is part of the reality it describes, and a particularly consequential part for the subset of entries that get weaponized.

Once you see this, the CVE count stops looking like a thermometer that happens to be badly calibrated. It starts looking like a weight scale that measurably bends the floor it stands on. You can make the scale more accurate, and it still bends the floor. The answer is to stop putting all the weight on one scale.

Stock and flow

This is the distinction that the industry has not internalized, and without it the CVE count is almost impossible to read correctly.

Imagine the cybersecurity threat landscape as two different quantities.

The stock is the accumulated pool of everything exploitable at a given moment: CVEs from ten years ago against unpatched systems, stolen credentials from old breaches, misconfigurations, zero-days nobody has disclosed yet, shadow IT, defaults that were never changed. The stock is enormous. It is what attackers have been monetizing every day for as long as the internet has had commerce. The total exploitation pressure against internet-facing systems — the aggregate volume of malicious traffic that honeypots and network sensors observe — is overwhelmingly a function of this stock.

The flow is how fast new vulnerabilities enter the stock in a weaponized state. A CVE published today adds to the stock tomorrow, but there is a period — the five-hour window — during which the vulnerability transitions from “public description” to “actively used in mass exploitation.” That transition is the flow. How quickly it happens measures the efficiency of the offensive pipeline: how fast do attackers ingest a disclosure, integrate it into their tooling, and deploy it against the internet?

These are two completely different variables, and conflating them produces most of the confused commentary you read about CVEs.

A year with zero new CVE publications would still have enormous exploitation pressure, because the stock of existing exploitable systems is independent of whether anyone catalogs new vulnerabilities. A year with 100,000 new CVEs, but all against obscure software nobody runs, could have rapid weaponization velocity on paper and no measurable increase in real exploitation pressure, because nothing vulnerable is actually deployed at scale.

The CVE count, as currently published, does not distinguish between these two quantities. It does not tell you whether the stock is growing or the flow is accelerating. It does not tell you whether the new entries represent real additions to exploitable attack surface or administrative catch-up on vulnerabilities that already existed. It mixes them, reports the sum, and lets the interpretation fall wherever the reader’s priors take them.

Almost everything defenders actually care about lives in the stock, not in the flow. The number you should want to minimize is the volume of exploitable systems that are actually being exploited — stock in its operational state. The flow matters as a contributor to the stock, but a year where the flow accelerates does not necessarily mean the stock grew proportionally, and a year where the count explodes does not tell you whether what you are looking at is more stock, faster flow, or neither.

Where the growth actually came from

To see why this distinction matters in practice, it helps to look at where the CVE count has been growing. The headline — 14,647 CVEs in 2017, 48,185 in 2025 — is blunt. The breakdown underneath it is specific and, once you see it, hard to interpret as anything other than a story about administrative capacity catching up to vulnerabilities that were already there.

From 1999 through 2016, the CVE program was centralized. MITRE ran most of the cataloging as a single organization, and the annual volume hovered in a band between 4,000 and 7,000 CVEs per year for a decade. The number fluctuated with MITRE’s bandwidth more than with anything happening in the software ecosystem. A year where MITRE was short-staffed looked like a calm year for cybersecurity. It was not.

In 2016 the program pivoted. The CVE Board approved what was called the federated growth strategy: instead of MITRE being the bottleneck, any qualified organization could become a CVE Numbering Authority — a CNA — and assign CVE IDs within its own scope. The idea was sound. MITRE could not keep up with the volume of modern software, and many disclosures were sitting in limbo for months because researchers had no one to submit them to. The federation was a fix for a real administrative problem.

The effect on the count was immediate. CVEs jumped from 6,447 in 2016 to 14,647 in 2017 — a single-year increase of 127%. No reasonable person believes that software became 127% more vulnerable in twelve months. What happened is that a disclosure backlog that had been artificially suppressed by MITRE’s capacity constraints got released when the federation opened up alternative pipelines.

After 2017 the volume settled into a new regime: roughly 1,400 additional CVEs per year on average through 2021. Still growth, but orderly growth, consistent with what you might expect from a mature federated system cataloging a steadily expanding software ecosystem.

And then came 2022 to 2025. The slope changes abruptly. Additions per year jump to 5,000, then 7,000, then 11,000, then 8,000 again. The catalog nearly doubles in four years. If you were reading this sequence in isolation, you would conclude that something serious happened to software security between 2021 and 2025.

What actually happened is more specific. Five CNAs account for most of the growth, and four of them either did not exist as CNAs before 2021 or were too new to have meaningful volume yet. Patchstack and Wordfence were both designated CNAs in June 2021 to handle the WordPress plugin ecosystem. VulDB was designated at the end of 2021, with a focus on open-source research disclosures. The Linux Kernel team became its own CNA in February 2024. GitHub, which had been a CNA since 2019, scaled its output over the same period.

By 2025, these five organizations collectively published more than 24,000 CVEs in a single year — roughly half the entire program. Patchstack alone went from approximately 250 CVEs in 2022 to 7,007 in 2025, ranking first globally and outpacing Microsoft by a factor of eight. Wordfence went from roughly 200 CVEs in 2022 to 3,525 in 2024. The Linux Kernel CNA, which did not exist in 2023, published 4,325 CVEs in its first year and has kept pace since.

If you remove those five CNAs from the dataset, the rest of the ecosystem — Microsoft, Red Hat, Oracle, Cisco, Adobe, MITRE, the long tail of smaller vendor CNAs — compounds at roughly 6% per year over the same period. Six percent is approximately the growth rate of the software industry itself. The residual is boring. The residual is what you would expect from a mature ecosystem cataloging a slowly expanding attack surface.

None of this is hidden. The CNAs themselves say it in their own publications, which is probably the most important detail. Wordfence’s 2024 State of WordPress Security report contains this sentence: “The process of obtaining a CVE ID was previously arduous and lengthy, requiring researchers to manage responsible disclosure independently. However, WordPress security companies like Wordfence, acting as CNAs, have streamlined this process, leading to a significant increase in WordPress vulnerability research over time.”

Read that carefully. The CNA responsible for a significant fraction of the CVE volume growth is telling you, on the record, that the growth is downstream of the process having become easier, not of more vulnerabilities coming into existence. Wordfence goes further and notes that 68% of the vulnerabilities they publish are considered low-risk for most site owners — cataloged things that, in the pre-federation era, would not have been worth the administrative overhead of obtaining a CVE identifier.

Patchstack tells the same story from a different angle. In their 2020 whitepaper, published before they became a CNA, they tracked 582 vulnerabilities in the WordPress ecosystem that year. Roughly 150 of those received CVE IDs under the old manual process. The other 432 existed and were documented in Patchstack’s internal database, but never entered the public count. By 2024, the same ecosystem produced 7,966 tracked vulnerabilities, and essentially all of them received CVE IDs. The conversion rate from “tracked vulnerability” to “CVE in the public database” went from roughly 25% to nearly 100% in four years.

That is not a cybersecurity crisis. That is a documentation catching-up event, concentrated in a few specific ecosystems — WordPress plugins, Linux kernel patches, GitHub-hosted open-source packages — where administrative capacity had been the binding constraint for years.

This is the part the topline CVE count does not show you. The 140% growth between 2021 and 2025 is not distributed across the catalog. It is concentrated in ecosystems that recently acquired dedicated CNAs, and the CNAs themselves attribute it to process improvements rather than to deteriorating software security. Anyone citing the growth rate as evidence of worsening cyber-risk is reading the topline without looking at the composition underneath it.

And yet the composition is where all the useful information is. The real questions are operational, not administrative. How much of the new catalog is actually being exploited? How fast does exploitation start once a CVE is published in the newly-covered ecosystems? How is the defender population responding? None of those questions is answered by the topline number, and all of them are answered — or at least answerable — by the three quantities I described above.

What a non-reflexive dashboard would look like

The reason this matters is that we do not lack alternatives. We lack the discipline to publish them in a form that is usable.

A serious cyber-risk dashboard would track three quantities that each move for reasons largely independent of the CVE catalog itself.

Exploitation pressure measures the stock in its active state: how much malicious traffic is actually hitting internet-facing assets, normalized per asset per month, segmented by industry. GreyNoise, ShadowServer, and national-level honeypot networks see this every day. They do not create the attempts; they observe them passively. A honeypot does not induce the attack it records — the attack would have happened whether the sensor was there or not. This is the closest thing the ecosystem has to a genuinely non-reflexive metric, and almost no policy conversation references it.

Weaponization velocity measures the flow efficiency: the median time from CVE publication to first mass-exploitation attempt, for critical vulnerabilities in popular software. This is the reflexive effect isolated and measured. Patchstack published the five-hour number once, for one ecosystem. We have no comparable number for Linux kernel CVEs, or for enterprise SaaS, or for network appliances. The number exists in the data that each of those ecosystems already collects; it is simply not published as a continuous time series.

Defensive friction measures how well the world responds once a known-exploited vulnerability has been cataloged: what percentage of the vulnerable population is still exposed 30 days after a CVE enters the CISA KEV list. Qualys has this across a billion remediation records. Mandiant has adjacent data in M-Trends. Neither organization publishes it at the resolution a regulator or a CISO would need.

These three quantities, read together, tell you what the CVE count by itself cannot. Exploitation pressure tells you how heavy the stock is. Weaponization velocity tells you how quickly the flow thickens it. Defensive friction tells you how fast the world drains it back down. They are correlated in discrete events — a specific CVE gets published, velocity fires, pressure spikes briefly against that CVE — but in aggregate they move for different reasons and respond to different interventions.

The reason we do not have this dashboard is not technical. The data exists, distributed across half a dozen organizations with different commercial incentives. The CVE count fills the vacuum because it is the only number everyone agrees to publish in the same format every year. The convention has become the signal, and the signal is reflexive.

Why this keeps happening

The deeper reason the CVE count persists as the industry’s default risk thermometer is that reflexivity is invisible when you only see the output. You read “48,000 CVEs in 2025, up from 28,000 in 2023,” and there is no footnote explaining which portion of the growth came from a new CNA being onboarded, which portion from existing CNAs scaling their pipelines, which portion from vulnerabilities being faster to weaponize than before, and which portion is real change in the underlying software. The topline number collapses all of that into a single figure that anyone can quote in five seconds.

The incentives to do that work are weak. Researchers produce volume because volume is what gets tracked. CNAs compete on volume because CNA scorecards are built around volume. Journalists quote the topline because the topline is the one that is published. Regulators build policy on CVE growth because CVE growth is the number they have. Nobody in the chain is specifically responsible for asking whether the metric is measuring what people think it is measuring. Everyone downstream assumes someone upstream checked. Nobody checked.

This is not unique to cybersecurity. Every industry has an indicator that accidentally became the conventional signal and that everyone now quotes without examining. GDP has this problem. Standardized test scores have it. Engagement metrics in software products have it. The pattern is always the same: a number that was designed for one purpose gets used for a dozen other purposes it was not designed for, and by the time anyone notices, the decisions that matter have been anchored to it for so long that challenging the anchor feels like an attack on the whole edifice.

The CVE count was designed to give defenders a common identifier for vulnerabilities so that security tools could interoperate. That was a good design for that purpose, and it still works. What it was never designed to do is answer the question “is cybersecurity getting worse?” — and the answer to that question is exactly what everyone has been using it to answer.

The operational implication

If you are a CISO, the practical takeaway is not optimistic. You cannot fix the reflexivity of the CVE catalog from your position. You can only stop organizing your program around it.

Separate vulnerability management into two pipelines with different tempos. The first handles the 99% of CVEs where disclosure is more defensive benefit than offensive cost — a normal cadence of prioritization, patching, and verification. The second handles the reflexive cases — the critical CVEs in software you actually run — on a tempo of hours, not days. That second pipeline is not a scan-faster problem. It is a virtual-patching, WAF-rule, compensating-controls, architectural-segmentation problem. It assumes the window between disclosure and exploitation is too short for a patch-and-deploy cycle to matter. It accepts that for the reflexive cases, you have to buy time for the patch to catch up.

For regulators drafting disclosure requirements based on CVE counts: please don’t. A threshold set at “X critical CVEs per year” either encourages volume, which inflates the reflexive component, or discourages disclosure, which pushes vulnerabilities back into the opaque-but-not-safer state. Anchor thresholds in exploitation telemetry or KEV entries. Those measure downstream outcomes rather than upstream cataloging decisions. They do not push CNAs to publish more or publish less. They measure what actually happens.

For vendors, CNAs, and anyone whose business model involves publishing vulnerabilities: every CVE published is an action that, for some fraction of the catalog, materially increases near-term risk to defenders who had no voice in the decision. That responsibility is not discharged by being technically correct. It is discharged by being well-timed, coordinated with the vendor, accompanied by mitigations where possible, and — for the worst cases — sometimes delayed beyond the standard window, even at the cost of a researcher’s publication credit.

Back to the macro problem

The reason any of this matters is that cybersecurity is increasingly a load-bearing public good, and the public good has to be governed somehow. Governance requires measurement. Regulators write policy based on what they can measure. Insurers price risk based on what they can measure. Boards approve cybersecurity budgets based on what they can measure. And right now, everyone in that chain is measuring the same thing — the CVE count — and it is the wrong thing to be measuring for the decisions being made.

The risk is not that we keep citing a flawed number. The risk is that we spend the next five years building governance infrastructure on top of it — the EU Cyber Resilience Act, SEC disclosure rules, national cybersecurity strategies, insurance underwriting models — and lock in a policy regime that treats a reflexive metric as if it were a passive one. Policies that are wrong but codified are much harder to fix than policies that are wrong but merely conventional.

What would help is not abandoning the CVE count. The catalog is useful, and the count is a fine administrative metric for the program itself. What would help is building and publishing the three non-reflexive quantities continuously, in a form that a regulator or a CISO can cite in place of the CVE count when the question is “is cyber-risk rising?”. Exploitation pressure, weaponization velocity, defensive friction. Stock, flow efficiency, drainage. Three numbers, updated quarterly, segmented by industry, published as a public good by whoever can coordinate it — CISA, ENISA, a cross-industry consortium, anyone.

Until that exists, the five-hour window is going to keep getting wider in the places that matter, the CVE count is going to keep getting quoted as if it meant something cleaner than it does, and every January we are going to have the same tired debate about whether cybersecurity is getting better or worse, measured against a number that is now partly a cause of the thing it is trying to describe.

Five hours. That is the real headline. And the reason it is not in anyone’s annual report is that it does not fit on a dashboard that was built for a different question.

TL;DR: Fit 8 candidate distributions to CVSSF per 1KLoC across 71 organizations. Lognormal wins (KS p=0.85), log-logistic ties it. σ_log ≈ 1.77 means a ~60× spread between the median and the P99. This isn't a quirk of the sample — it's the predicted shape when defect rates are generated by multiplicative processes (Mullen, ISSRE 1998). The post breaks down the five factor families the literature has identified as the multipliers: complexity, churn, developer activity, process maturity, and product attributes. And why reporting means, stdevs, or linear improvement targets on this kind of distribution is statistical malpractice.

A few weeks ago I was looking at a chart with 71 bars. Each bar was a different organization, and the height was the density of open severity per thousand lines of applicable code — the metric we use internally to benchmark how security-debt-laden a codebase really is.

The tallest bar was 1,546. The shortest was 0.1. Same metric, same unit, same methodology. Fifteen thousand times more severity per KLoC in one organization than in another.

My first reaction was the reaction anyone has when they see a bar chart that ugly: these numbers must be wrong. The second reaction, after ten weeks of re-checking the pipeline, was worse: these numbers are right, and I don’t know how to talk about them.

Because if I report the average, I’m lying. The mean of that dataset is 91.8. Exactly one of the 71 organizations is anywhere near 91.8 — the rest are either well below or way above. The mean is an artifact; it describes nobody.

If I report the median, I’m closer to honest — it’s 22. But the median doesn’t tell me why some organizations are at 1,500 and others at 0.1. It just tells me where the middle is.

So I did what you do when the usual summary statistics betray you: I asked what shape this distribution really has. And the answer, it turns out, is not an accident. It’s the only shape this distribution could possibly have, given how software actually gets built.

The fit

After fitting eight candidate distributions against the data — lognormal, Weibull, gamma, exponential, Pareto, power-law, log-logistic, Burr — two of them came out indistinguishable at the top: lognormal and log-logistic. Kolmogorov-Smirnov p-values of 0.85 and 0.98 respectively. The Shapiro-Wilk test on the logarithm of the data gives p = 0.56, which in plain English means: once you take the log, the distribution is statistically Normal.

That’s the definition of lognormal. If log(X) is Normal, then X is lognormal. Parameters: μ_log ≈ 3.06, σ_log ≈ 1.77. Translated: a typical organization sits at around e³·⁰⁶ ≈ 22 CVSSF/KLoC, and the σ in log-scale is so wide that the organization at the 99th percentile has roughly 60× more severity density than the one at the median.

This is not a dataset anomaly. This is the shape severity density has always had, and will keep having, because of the mechanics of how the metric is generated.

Why lognormal and not Normal

Normal distributions come from adding many independent small causes. The classical textbook example is the height of adult humans: your height is the sum of thousands of small genetic and environmental contributions, each pulling you a millimeter one way or another, and the Central Limit Theorem guarantees the sum is Normal. That’s why nobody is 15 meters tall. Additive processes have thin tails.

Lognormal distributions come from multiplying many independent factors. If X = f₁ × f₂ × f₃ × ... × fₙ, then log(X) = log(f₁) + log(f₂) + ... + log(fₙ), and that sum is what becomes Normal by the Central Limit Theorem. When you exponentiate back, you get a lognormal — with a fat right tail where a few observations can be orders of magnitude larger than the median.

This is not a statistical curiosity. Robert Mullen established the theoretical case back in 1998, in a paper called The Lognormal Distribution of Software Failure Rates: Origin and Evidence, published at ISSRE. His thesis is blunt: the lognormal distribution has its origin in the complexity of software systems — the depth of conditionals — and in the fact that event rates are determined by an essentially multiplicative process.

Mullen and Gokhale later extended this to defect repair times over more than 10,000 defects at Cisco Systems, and then to security-related defect counts specifically, where they proposed a Discrete Lognormal model. The line of evidence now spans three decades.

The intuition is this: a vulnerability doesn’t appear because of one thing going wrong. It appears when several things go wrong simultaneously. The function is too complex and the developer was junior and the code was recently churned and nobody reviewed the PR carefully and there was no SAST in the pipeline and the component happened to receive untrusted input. Each condition is a multiplier. Miss any one of them and the vulnerability probably doesn’t ship. Hit all of them and you get hacked.

When you multiply probabilities, you get lognormal. When you add costs, you get Normal. That’s the math.

The factors, named

The part of this I find most useful as an operator is not the distribution itself — it’s the identification of which factors actually do the multiplying. The literature on defect and vulnerability prediction is surprisingly specific about this. I’ll compress two decades of it into five families.

Family 1 — Code complexity. McCabe’s cyclomatic complexity, nesting depth, function size, fan-in/fan-out, CK metrics for OO systems. Shin and Williams were the first to show systematically that complexity metrics discriminate vulnerable from non-vulnerable code. Individually, the correlation is modest. Multiplicatively combined with the others, it becomes devastating.

Family 2 — Code churn. Nagappan and Ball at Microsoft Research established in ICSE 2005 that relative code churn — the proportion of lines changed to total lines, and the temporal concentration of those changes — predicts defect density with 89% accuracy on Windows Server 2003. Not how much the code changes in absolute terms. How much it changes relative to its size, and how concentrated those changes are in time. Files that mutate rapidly are files that break.

Family 3 — Developer activity. Number of developers who touched a file, concentration of authorship (your bus factor), ex-developers who left, experience in that subsystem. Meneely and Williams showed that when many developers touch a file without clear ownership, vulnerability probability spikes. This is the human version of churn: it’s not the number of hands, it’s whether any of them knew what they were doing.

Family 4 — Process maturity. Here the evidence is at organization level, which is where we live. Staron and Meding studied 61 projects in 2012 across CMMI maturity levels. Median defect density: CMMI 1 = 4.1, CMMI 3 = 3.0, CMMI 5 = 1.25. Ratio of worst to best across process types in their sample: Cowboy dev 5.8 down to Hybrid 0.7, roughly 8× difference just from process. The Software Engineering Institute reports 71% defect density reductions on average from SW-CMM to CMMI Level 5. This is the factor that most organizations underestimate the most, because nobody likes admitting that how you work matters more than who you hired.

Family 5 — Product attributes. Language (C/C++ carries vulnerability classes that Java and Python simply don’t have), project size, code age, whether the component receives untrusted input. Attack surface exposure concentrates vulnerabilities in ways that dwarf most other factors for the handful of files on the boundary.

Five families. Each one multiplicative. Each one roughly independent of the others — your CMMI level doesn’t dictate your choice of language; your team’s tenure doesn’t dictate your churn rate. Multiply four or five of these together, each contributing a factor of 2× to 3× between best-in-class and worst-in-class, and you get exactly the two orders of magnitude of spread that shows up in the data.

What this means for anyone who has to talk about security numbers

If you’re a CISO, a security vendor, a consultant, or an industry analyst, here is the operational consequence of all this, and it’s uncomfortable.

First: stop reporting means. The mean is a lie for any metric that lives on a lognormal. I see industry reports constantly saying things like “the average organization has X vulnerabilities per million lines of code.” That number is meaningless. It is dominated by the worst three or four organizations in the sample. Use the median, or better, report the full distribution with P25/P50/P75/P90.

Second: stop using standard deviations as error bars. A Gaussian confidence interval around a lognormal mean produces intervals that often include negative values — physically absurd — and that miss the actual uncertainty by a wide margin. Work in log-space, or use quantile-based intervals. If you’re comparing two organizations and their densities differ by 3×, that looks huge in linear scale but is roughly one standard deviation in log-scale. It may not even be a real difference.

Third: stop treating outliers as outliers. The organization at 1,546 CVSSF/KLoC in our data is not a data error. It’s a prediction of the model. Lognormals produce a few extreme values by construction. If you cut the top 5% because they “look anomalous,” you’re not cleaning your data — you’re censoring the exact observations that carry the most information about the tail.

Fourth: stop promising linear improvements. Moving from 200 to 100 severity per KLoC is not twice as hard as moving from 100 to 50. In log-scale, both are one stop. That’s why organizations that already have good hygiene find it so hard to improve: they’re fighting against σ_log, not against raw counts. Remediation ROI is logarithmic, not linear.

Fifth: accept that the tail is where the risk is. If 10% of your portfolio of assessed organizations concentrates 70% of the open vulnerabilities — and with σ_log = 1.77 they do, almost by definition — then your remediation strategy cannot treat all clients equally. Triage is not a preference. It’s a consequence of the shape of the distribution.

The reason I’m writing this

I’m a systems engineer who’s ended up spending a lot of time on the wrong end of bar charts. And what I keep finding is that the security industry — especially the compliance-theater segment of it — traffics in statistics that assume Normality where there is none. Dashboards with averages. Reports with standard deviations. Benchmarks that say “the industry average is X” without ever asking whether the industry average is a number anyone actually has.

The shape of severity density is not a mystery. It has a theoretical explanation that’s held for 30 years. It has five named factor families that each independently contribute to the multiplicative cascade. It has a consistent signature — fat right tail, median well below mean, σ_log around 1.5 to 2.0 — that shows up whenever someone measures it honestly.

If you are buying, selling, or reporting on AppSec, and the numbers you’re looking at don’t account for this, you are looking at an average height of organizations where three of them are blue whales.

The math does not care whether your dashboard is pretty. It cares whether your dashboard is true.

Data and model: 71 organizations assessed by Fluid Attacks. CVSSF Open Vulnerability Density per 1KLoC on applicable lines of code. Best fits: lognormal (AIC 720.3, KS p=0.85) and log-logistic (AIC 719.0, KS p=0.98), statistically indistinguishable at this sample size. Theoretical foundation: Mullen, R. E. (1998, ISSRE); Gokhale & Mullen (2010, Empirical Software Engineering 15(3)); Shin, Meneely, Williams & Osborne (2011, IEEE TSE 37(6)); Nagappan & Ball (2005, ICSE); Staron & Meding (2012, ESEM); Concas et al. (2011, IEEE TSE 37(6)).

TL,DR: We are living through the greatest moment of technical excitement in decades, and at the same time an avalanche of misinformation about what frontier models can and cannot do in security. This article argues three things: that we will have more vulnerabilities deployed in the world, not fewer (Jevons effect); that the asymmetry between spelling and security is not commercial but computational (Rice, undecidability); and that finding vulnerabilities is a property of a system with a human in the loop, not of a model. The practical conclusion: most organizations should stop worrying about hypothetical master keys and start remediating the backlog they already have.

Since January 2026 I have lived through the greatest period of technological excitement of my life. I’m 44 now, and I’ve gone through several inflection points: having a 286 at age 8, then discovering that viruses existed (software that copies itself), then the Internet and its universe of information, learning that Linux existed and that I could run a Unix on a 486, being part of a community like Debian, getting a handle on Nix and NixOS, and now coding agents. It isn’t new for me to live through the moment when everything you knew stops being useful and you have to relearn. But only Linux and code-writing LLMs are comparable in magnitude.

In January 2026 I called the CEO of the company and said: “Vladi, the programming workflow has changed. Claude Code CLI and Opus 4.6 do different things. I’m asking for authorization to ban direct programming at Fluid Attacks and, starting February 1st, to give proper licenses to the entire engineering team. Since that is the only thing changing, we can treat it as a temporary experiment and compare our process metrics — mature and in place for years — against those of February and March.” They backed me, and here we are.

It might seem this was the transformation, but ever since LLMs broke out in 2023 — a moment that didn’t hit me with the same intensity — we started building a separate engineering department, attached to the Analytics division, so we could experiment with the new stacks available and leverage our vision for vulnerability management. The first bet was to try to hire experts in the field, which instead yielded talent who wanted to learn about it rather than people who already knew. So we decided, radically, to move internal engineers into the new area and start attacking multiple problems. Since 2024 we have in production vulnerability detection agents, prioritization models, dynamic patch generators, correlators between threat models and vulnerabilities, code contextualizers, AI-powered Pull Request analyzers, and countless internal tools not worth mentioning here. This context matters because it makes one thing clear: the excitement of January hit me even though we had been working across many AI areas for years.

This moment of excitement is the moment when you open a door and see a new world. It’s like seeing colors you hadn’t seen, smelling smells you hadn’t smelled, and they keep appearing and growing. A moment when I see a countless world of possibilities for us and for humanity. A moment when I believe that not only will software be better and tackle more problems, but that mathematics and the world of management will finally enter into symbiosis. Applying operations research used to be a crazy dream in any company that has to move fast. Now Monte Carlo analyses and assignment problems get solved beautifully in an hour, just by asking the right questions. It isn’t only software: it’s mathematics and rigor in the service of management.

I’m ecstatic to be living this moment of the world, to see how day by day we get better at many things, how the team is slowly starting to believe, and how we do things that used to be impossible. Rapidly increasing test coverage, remediating vulnerabilities faster, putting our dumb tests to the test with mutation testing, writing Rust, shipping faster and more deterministic components that save time for our clients. It isn’t only excitement: it’s watching it spread across the team.

And yet all this excitement turns against me when press announcements start coming out in which Anthropic says it will release a component that reviews code security. Every security company’s stock drops, and I ask myself: what’s the logic? Okta — one of the most relevant companies for the future of AI — drops? Why does something drop that has nothing to do with this? The world now believes Anthropic will replace the category with its next model. It already happened with the SaaS apocalypse; then they pull it off in another category and it lands. It makes very little sense to me off of a press release, because OpenAI announced the same thing in October 2025 — they didn’t ship the software, and nothing happened to their stock. Just another announcement. In other words, Anthropic’s momentum has bought it credit for everything. And yes, it is madness, I love it, I use it, I pay for it, heavily. But does it deserve credit for everything it says? No. Nobody has that credit — not my mother, not God. Everything has to be analyzed.

I thought that was enough, and when I came back from vacation I ran into Mythos: more press releases about the same thing. A model so dangerous it sounds like plutonium. The idea was almost to sell it as a weapon of mass destruction that only the good and the powerful could access. I review, and review, and review; with long and severe claims, they show it is almost the master key to any system, that hacking has changed, and that the world is over. I start looking — with AI, obviously — for the confusion matrices and F-scores of the process. That is: in the search for those 500 or 1,000 vulnerabilities, how many did the model report as vulnerabilities that weren’t? In other words, for every confirmed real vulnerability, how many false positives were reported? Information not available. I look for how much compute, how many tokens — at prices for mortals like us — were used in the full process. Information not available. I look for CVEs growing at a scale matching the noise: not there. I look for an uptick in public exploit databases: no exponential increase. I look for information on the architecture of the process and, although we have some details, there is no real clarity there either. That last part I understand better.

Now, let’s understand this: vulnerabilities and the process of finding them require the following — the source code of the system, the running system, deterministic tools coordinated by the model (that’s why it’s an agent), and all of this inside an infinite feedback loop in which files get prioritized, vulnerabilities get searched for, and through execution, real findings are triaged from the noise. You can imagine that this whole setup, for something like OpenSSL — as mature as it may seem — is easier to assemble than standing up an ERP, a CRM, or a distributed system. Building that setup is called a harness, and a human builds it. A human selects the ToE, a human assembles the harness and, more importantly, someone — after infinite outputs of candidate vulnerabilities — confirms whether they’re real or not. The process of discovering vulnerabilities with seriousness and responsibility is a process with tools, yes, but one where humans play a relevant and beautiful role. And it is so for the good of all. So much so that now, in the world of automation, a human at Anthropic says: don’t ship the software to production, only sell it to your friends first.

The worst moment hadn’t arrived yet. Over the following days, friends, enemies, clients, peers, strangers, family members barely aware of the topic, repost and forward shallow journalism that is the leftover of another announcement. The announcement of the announcement, everyone surfing the hype. Everyone caught up in the master-key frenzy, chasing more clicks for their posts; few, very few, retweet the people trying to break down the scope and the moving parts of this. That’s why I decided to write this article: because I can’t transmit this much information — against this much disinformation — with a simple voice note. I went back to blogging, in this case to get back at those who forward in a second: I’ll respond properly, stealing 30 minutes of their time with the longest article of my life.

An analogy and a question have helped me explain both the problem and the solution, without ignoring that the trajectory here is impressive and that in the future we will have a better world. Question: in the long run, will we have more vulnerabilities or fewer than today? Ask yourself before going on. The answer is simple through this analysis: we will have more programmers than today — this got democratized. Those programmers will produce more lines of code per person than before — LLMs are beautiful. And we will have fewer vulnerabilities per thousand lines of code, no doubt. Will the security they vomit out be better? The data today doesn’t show that; today they spit out more vulnerabilities than a human does. But, for the sake of argument, let’s assume the process improves along the trajectory it’s on. More programmers, more lines of code, and lower density give you more vulnerabilities deployed in the world. Not fewer. Because the quantity of lines of code being created today is so disproportionately higher — orders of magnitude above the improvement in vulnerability density — that it generates a larger attack surface, with more nominal vulnerabilities. Ergo: more incidents. Just like efficient LED bulbs didn’t lower consumption, they raised it: we bought more bulbs and lit up more spaces.

The analogy, for its part, is this. If an LLM always responds with good spelling, why doesn’t the LLM always respond with good code? Why, in spelling, aren’t we sold two products — the one that writes and the one that corrects the spelling — but in security we are sold two products: the one that writes code and the one that corrects code? What does spelling have that security and vulnerabilities don’t? In the answer to this there are beautiful things, said by the very same frontier-model providers. Spelling, unlike security, is local, deterministic, non-adversarial, and of low asymmetric cost. Security, in contrast, is global, contextual, adversarial, and of high asymmetric cost.

Spelling is local because a few elements in a paragraph are enough to judge whether a word is right or wrong. That’s what lets it be embedded inside the model. A vulnerability is global because it arises from the chaining of many moving parts: an unfiltered input in a file, the destination of that information in a database, an incorrect dependency, a misconfiguration, or any combination thereof. Many pieces make up a vulnerability. Spelling is deterministic because there is a revealed truth: there are language academies that say “these are the rules,” period, no debate. In vulnerabilities, determinism is a dream: what’s a vulnerability in one system or one use case isn’t in another. In spelling, nobody is trying to hurt someone else because an accent is missing here or there; in security there is the adversarial side, where people are constantly hunting for flaws to cause damage. And finally, spelling has a low asymmetric cost — you look bad if you write badly — but in security, if you have a vulnerability, the cost to your company’s image and to your users is much greater than looking bad: it involves money, serious money, and even lives.

There is something even deeper behind this difference, and it's worth naming. Since Turing in 1936, we have known that no algorithm can decide, for an arbitrary program, whether it will terminate. Rice's theorem, a direct corollary, extends the result: any non-trivial semantic property of a program — "does it have a security bug?", "does it never dereference a null pointer?", "is it equivalent to this other one?" — is equally undecidable. It isn't that we don't yet know how to solve it: it can be proven that no algorithm can, in the general case. That's why every SAST, every type checker, every model checker is, by construction, an approximation: it either over-reports with false positives, or under-reports with false negatives. There is no escape, and there never will be. That's why TLA+, Coq, and Lean4 require a human to supply annotations, invariants, and tactics to close the gap. Spelling is decidable. Security is not, and never will be. The difference between the two products isn't a lack of engineering: it's computability theory.

Again, I insist: why are there two products and not one? Why doesn’t it vomit out perfect code in one shot?

This avalanche of information has produced something very positive: an urge to remediate, a concern about security. And I ask myself: why now? Because of an announcement? Well, the “why” of how they reach a good conclusion through a flawed process shouldn’t really matter to me. But it worries me, because when you conclude that way, today it’s good and tomorrow it’s bad. That is, there’s no consistency, no method, no system: we react to fear. I forget that people are inherently irrational and that the actual course of decisions really is like this. But it makes me sad. And more paradoxical still: many organizations already have vulnerabilities we reported to them long ago, through similar processes, and today they’re writing about how costs will drop, whether AppSec will disappear, whether hackers will become unnecessary, and what they should do to protect themselves from this new threat. The only thing they need to do is worry about remediating their backlog of vulnerabilities — which people have been postponing out of sheer laziness, wasting time prioritizing — when in reality it is possible to remediate all of it if the internal processes are put in place, at highly reasonable values.

With all that in mind, here is my response to everyone forwarding links: the models are advancing impressively, and we embrace it with excitement; but today the density of vulnerabilities has grown, not dropped. I do believe it will drop in the future, but even so we will have more vulnerabilities, not fewer. Incidents will be larger. The models, trained on insecure code, are propagating many vulnerabilities today. The frontier-model providers killed the spell-checker industry because spelling is local, deterministic, non-adversarial, and of low asymmetric cost; but vulnerabilities are global, contextual, adversarial, and of high asymmetric cost. And finally, a model doesn’t find vulnerabilities: a system, a pipeline, finds vulnerabilities. A system made of a harness around a running system, its source code, deterministic tools that the model orchestrates in order to find vulnerabilities, and a human who assembles all of that for each particular system and who then triages an output that is never perfect. And a system like this, is model agnostic, doesn’t even require frontier models: older, cheaper models are already being used to find vulnerabilities economically today, so the marginal gain from the frontier is smaller than the headlines suggest.

What worries me most is the misallocation of attention. Most organizations already have a backlog full of known vulnerabilities they are not remediating. They know exactly what is broken, and they are not fixing it. Yet they are anxious about a hypothetical master key that opens everything and hasn’t even shipped to production, when what they should be doing, with discipline, is remediating what they already know is wrong.

P.S: Vomited straight from my brain, no spellcheck, no human revision afterwards, then run through the prompt: "fix spelling, grammar, and narrative coherence". And that result run through another: "translate to English". All of it by Opus 4.7 Adaptive.

TL;DR

NixOS is a distribution with novel concepts including:

1. Native configuration as code using a uniform language: NixEL.

2. Reproducibility between the specification and the software installed.

3. Full rollbacks, even if a libc or kernel update fails.

4. Multiple versions of the same packages can coexist for several non-privileged users.

5. An insane quantity of prepackaged software: >40K.

6. The package manager works on top of most Linux distros and OS X.

This post will cover in detail why I made the switch despite my previous track record and the extreme difficulty for an old software engineer now converted into a manager.

First, I illustrate my experience with Slackware Linux. Second, I present the reasons why I moved to Debian and stuck to it for many years. Third, I describe a couple of incidents and day to day situations that led me to the Nix discovery. Fourth, I explain how to transition to it. Finally, I summarize the main points and present some reflections for the future.

Argumentation

My first love was Slackware, a distribution that forced me to do everything by hand because of its pretty basic package management system. During 1995 the internet connections in Medellín, Colombia, were awful. Downloading a Linux installer using a 28.8 Kbps modem needs patience and money. Through IRC, I managed to meet someone in town that sold me the current Red Hat and Slackware installers. Strangely Red Hat didn't work, and Slackware famous for being hard, ran smoothly. After that moment, my long trip to do everything from scratch began. For each application and its dependencies, I needed to:

1. Download the upstream source.

2. Read the upstream documentation.

3. Compile.

4. Install.

5. Configure.

6. Back up configuration files.

7. Document my tweaks for future use.

Mostly, I moved software from one place to another for years.

Near the year 2000, I planned to switch to a project that followed a similar development process as the Linux kernel and recently improved his already large and mature package management system: Debian. This project had clear guidelines to contribute, a bigger community, a broader software ecosystem, homogeneous documentation, and the most advanced dependency management I had ever seen. Everything became clear: less time downloading, compiling, installing, configuring software, or its dependencies. Just one command and everything arrived at my machine as expected. How not to become part of it? I fell in love again, and this time for a long time.

During all these years, my friends and I became Debian Maintainers, taught at universities, built a company, helped customers, made a private custom distribution, and became hobbyists during nights and weekends with the power of Debian, however, perfection was not even close. It was versatile, mature, stable, and relatively easy to handle in scale to solve several types of problems. However, despite using tricks such as preseeding or cfengine, each installation became what is now known as a snowflake, a unique piece of technology. If you wanted to install the same server, you still would need manual steps that inevitably never gave you the same result. You moved one thing, and another was broken. A minor software update silently occurred, and something that worked before didn't work anymore. Moving software was not only a complicated and expensive business but also a very fragile one.

In 2016, a discrepancy between software versions used to build an estimation was the root cause of financial disaster for a project. We had been using CLOC since 2012 to measure the source code size of an application that would be security tested. With this output, during the presales stage, we estimated the price following a simple formula. During the execution phase, we detected an inconsistency in the size of the application currently under test. As we went deep, we realized that different CLOC versions were in use. Again, a problem related to moving software.

Then I found a strange tool called Nix, that with its companion set of packages called Nixpkgs, could erase the problem from the face of the earth. This tool could be installed easily on every Linux, allowing us to maintain the OS anarchy policy that we had until now. Nevertheless, it would enable us to deliver the same piece of software to every possible person within seconds. The tool looked weird at the beginning:

1. Installing everything under /nix (store) is a clear violation of the FHS.

2. Most files are symbolic links pointing to weird names in the store.

3. To install a single package for all the users, you need to change a configuration file and “rebuild” the OS.

4. Each change creates a new entry on GRUB.

5. The disk gets full pretty fast, thus requiring a garbage collection process to remove the waste.

Despite how strange it was, it promised predictability, a requirement that was not always fulfilled, even for Debian, the distro with the strictest build policies and the better maintenance guidelines.

To personally experiment all the promises of this exotic beast, I decided to use it in my daily job gradually. From 2016 to 2017, I ran a Nix subsystem on top of my Debian Unstable. Then, I moved to NixOS over a virtual machine to find the workflows that fitted my needs and to get confidence to throw away my old habits. In 2019, I moved my host OS to NixOS unstable.

When I was forced to change my laptop twice, I received the validation of all Nix's promises were real. Just formatting the new machine, cloning the git repo that contained the full OS configuration, and waiting for the “build” process to end, gave me the same machine that I had before. Like in functional programming languages, it seemed like a pure function: the same output for the same input with no side effects. Since last year, the times of wasting effort moving software or catching bugs related to it are over.

Summary

After installing and using GNU/Linux for almost 24 years, I would say that the time spent moving software from one place to another is enormous. The implications of bad deployments are even more significant than the wasted engineering effort. Debian is still a pretty fantastic piece of work of the OSS community, and its habits are enrooted in many of us. However, Nix and its friends are solving the deployment problem tackling it from its roots. They are redefining assumptions and bringing a new era of stability, predictability, and joy for engineers. I hope that Nix prospers and will be the standard for many distributions in the future.

Conclusion

The main problem in achieving this future lies in the attraction of top developers from other distributions. Gentoo, Arch, and Debian are pretty vibrant communities and full of highly skilled developers. However, many of them remain skeptical when confronted with concepts like derivations, generations, store, rebuild, rollback, infra as code, non-GUI installation, flakes, etc. They think that Docker, Ansible, or other similar tools solve the same problem quickly, but the only way to convince them is by raising awareness of how much time they are still wasting moving software.

#linux #slackware #nix #nixos

Thanks to the possibilities of A/B testing, I decided to experiment by performing multiple tests on some of their advice. And to my surprise, the results were different from predicted.  I guess the experts weren't wrong, just that testing shows that in the business world, silver bullets don't exist.

The experiment I'm going to tell you about here was very simple.  Should the action on a landing page be at the top or the bottom?  The conventional wisdom of my close advisers was, unanimously, that it should be at the top.

To test this silver bullet, we designed an experiment where we ran the variations simultaneously for 40 weeks after first restarting the statistics.  The action with which we measured the conversion was the page display vs click on the "I WANT TO BE HEALTHY" button. (Here shown in green, “QUIERO SER SALUDABLE”). What does the experiment tell us about this silver bullet?:

In the table above we see three variants: A, AA and B. Variants A and AA have the button at the top of the page:

Variant B has the button at the bottom of the page:

As we can see in the first image, the conversion rate of the A and AA variants is between 6.10% and 7.63% (average 6.86%). However, the B variant has a conversion rate of 13.70%, a 79.55% improvement over the best previous conversion.

The difference between variants A and AA followed another, more subtle suggestion, where I was told I should change the order of the sections:

Again, the change proved to be insubstantial and contrary to the recommendation. The difference in conversion rate between Variant AA and Variant A was marginal (1.53%), that is, practically statistical equality. Andin any case the original Variant A, where “investment” appeared before “experience”, proved to be better.

The simple conclusion is that if someone gives you a silver bullet solution, you have to test it out.  In the long run the circumstances surrounding a business context are usually different and the important thing is to make identifiable changes one at a time, measure, compare, go back and repeat.

It all possibly began with good intentions (causes), but really it presents great problems (effects) for the technology industry of our country.  It’s even evolved a variation that looks different at first, but is really nothing more than the same problem on a different scale: "body shopping", or, as I call it, butt month.  

In this article we’re going to examine what this problem is and what are its causes and effects, so that in future articles we can look at better alternatives.

In a nutshell, butt-hour services are when someone charges you for sitting on their butt.

Let’s use an easy-to-understand comparison that’s similar enough to providing technology services: painting a house. When we look for someone to paint our house, we’ll find two types of service providers:  the butt-hour painter and the results painter.

The butt-hour painter will give you a quote for painting the house without looking at it. His model doesn’t consist in selling you the solution itself, but rather only part of the solution, which in this case is the painter's time.

The butt-hour painter will say that painting the house costs $30K COP per hour per painter. On the off chance that he visits the place, he may inform that the process will take between 5 and 10 days. However, the fine print will say that this duration is not guaranteed because other factors are out of his control (opening hours of the house, availability of materials, etc.).  The butt-hour painter will indicate that the paints and brushes are also not included and that you can buy them according to your needs. Typically you pay the painter these “butt-hours” in agreed time periods (weekly, fortnightly, etc.).

The results painter, on the other hand, visits your house, takes measurements and photographs, recognizes the area, determines the quality and color of the paint you require, and after understanding the problems and risks inherent in painting your house, will indicate that the process will cost a total of $3M independent of other variables.  

This painter also indicates that the job can take between 8 and 12 days, but clarifies that finishing the job earlier or later won’t affect the price. Payment is not according to specific timeframes but rather to progress on the overall result (milestones): for example, a payment of 20% when the courtyards are finished.

You as a reader, whether customer or supplier, can now probably quickly identify what percentage of your purchase or sale of technology services follows the model of butt-hour painters or results painters. I.e., IT guys who charge by the hour until the job is finished, or IT guys who charge for getting the job done, regardless of how long that might take. And I’m sure you’ll agree that in the IT sector of our country, the butt-hour model is the king of transactions. It’s the model most preferred by buyers, and the easiest to market for sellers.  

Let’s compare some attributes of both types of painters to understand how we as computer specialists essentially became nothing more than IT staffing agencies and that our relevance as an industry is in jeopardy.

The first thing to analyze is the total cost of the solution.  The butt-hour painter is selling only part of the solution and not the solution itself, so his quote is a unitary value of labor and not the closed value of a solution to a problem.  

With the results painter the final total cost is known in advance, therefore the operational risk is fully transferred to the supplier.  The butt-hour painter can sit on his butt and dawdle if he wants, spend an hour more, an hour less, spill a can of paint or two, and we’ll only know the total cost of everything at the end.  

From the buyer's perspective, opting for the butt-hour painter is to hope that by managing the variable costs of labor and materials the job will turn out cheaper than what the results painter charges. But do the theoretical savings of cheap butt-hours compensate running the operational risk?

A buyer has to put in a lot of cost management to ensure that his butt-hour service will end up cheaper, and this brings with it a whole slew of hidden costs.

Optimizing painter hours and materials implies spending time and money on the part of the buyer to ensure the proper use of resources: counting painter’s hours, negotiating hours, selecting and purchasing materials, among others.  

In the butt-hour model the buyer acquires administrative responsibilities in which easily managers of the parties invest two hours of their time each discussing whether a painter arrived at 8:00 AM or 10:00 AM to know if one, two, or no painter butt-hours should be paid. After subtracting the hidden costs, is the cheap butt-hour still cheaper?

A dimension apparently in favor of butt-hour painters is the speedy capacity to deliver a quote, and the low investment needed to make the sale.  

When you paint a house in butt-time you don’t have to estimate or precisely define the task at hand. You don’t have to measure the area of the house, you don’t have to make a detailed estimate, you don’t have to determine the type of paint, you don’t even need the house to be built already, or to have a house at all. You just send a price list in advance quoting a unit of time, so you barely have to spend any time preparing a quote, nor invest anything in attempting to make the sale. But is it really cheaper to not know what I have to do instead of investing in specifying the result I want?

Since butt-hour painters all use the same quoting unit—that is, the painter’s hour—, this model gains an advantage when being evaluated by the Purchase Department: supplier comparability.  If there are several butt-hour painters, you can compare them by looking at their skills rather than the quality of their work. For example, you can filter for painters with over two years of experience who are certified in heights and handling toxic materials.  

Suppliers who submit their price quote assure you that they will supply painters with the requirements you specify, and it’s assumed that painters who fulfill these requirements will all deliver the same quality of work. So when you compare quotes you’re not really comparing quality since supposedly it’s all the same—all you’re comparing is the hourly price. However, isn't it cheaper to have a supplier who is twice as expensive per hour but is four times as productive?

Taking all this into consideration, we can clearly see that the butt-hour service model encourages dawdling. Obviously, painters charging by the hour will be motivated to overestimate the time required for the job, or report more time than was actually spent.

Whereas on the other hand, the results model encourages innovation. Results painters must constantly be on the lookout for new technology or working strategies that will allow them to meet the defined objective in less time and cost.  

Butt-hour painters are very unlikely to develop and incorporate innovations, because doing things more efficiently means they’ll spend fewer hours doing the job—and therefore make less money. And anyway, innovating takes effort. Why would they do that if it gives no return? Better to keep sitting on your butt.

So, how can you innovate while in a company that works under the model of selling butt-hours?

You can’t.

The only option is to get rid of the model.

When there’s a contract between companies at a fixed value of butt-time, the supplier has to hire staff with a standard productivity and cost that lets him generate a profit margin.  So a paint company that uses the butt-hour model for services must pay all its painters pretty much the same. Therefore, there’s little space for the development and retention of exceptional talent. Painters won’t learn how to do a better job, and those that do, will leave. Retaining painters that can paint twice or triple the area per unit of time would imply having to pay them more, increasing cost without increasing income even when there’s a potential perceived benefit for all parties. 

For obvious reasons, in a results model the space for exceptional talent and wage differences of up to 3X or 4X are perfectly viable. Where would you as a buyer rather work, in a butt-hour company or a results-based company?

One thing that buyers like about the butt-hour model is that they can try to micromanage everything.  Since the buyer is trying to manage everything himself and find the absolute cheapest way to get the job done, everything can be challenged.

The time spent stirring the paint, how long the painters take for lunch break, what time they arrive and leave, the painting speed of Painter A compared to Painter B, the painting speed of everybody compared to the fastest painting speed of the best painters in the world, the method of painting, the use of brushes instead of rollers, everything.

Roles are challenged or replaced by the buyer himself or even supplied by the competition.  Essentially the buyer of a butt-hour service becomes the operations manager, research manager, and development manager of the supplier.

The ability to manage their own equipment ends up being a luxury only had by the results painters, whose method of work and hiring gives them the independence to achieve the results they initially committed to in their own way.

Why hire a painter and tell him how to paint? Could it be that in the long run you purchase capacity because you want to control more people? When the buyer gets to compare painter’s hours and challenge every part of the process, he ends up running the job his own way. Added to the standardization of skills and appraisal of man-hour price, butt-hour painters end up succumbing to disaster: commoditization.  

Now, the only thing that sets competitors apart is price. Essentially, the butt-hour painter goes from being a tech company to being an IT staffing agency. Meanwhile, the results painters get to keep their own method, technology, work culture, and continue to supply final results rather than man-hours.

Once man-hours (or butt-hours) have been commoditized, the sale moves on to the next stage: granularity. Here we add the client's micromanaging to his incessant search for cheap deals, so now he doesn’t want us to pain the whole house, he just wants certain walls, or certain parts of walls, or to patch up a hole left by a nail where a picture used to hang.

These small one-or-two-hour tasks end up generating sales that don’t even cover the fixed costs of the remaining six or seven free hours that can’t be assigned to that painter in another patch-up job on the same day. After a while the small projects start to outnumber the large ones, and butt-hour painters start bleeding out in their financial results.

Some savvier companies have understood the problem of granularity and have moved to a more advanced version of the butt-hour: the butt-month! (I.e., “body shopping”, SCRUM included). This way they avoid granularity, and whether or not the painter is busy painting houses, they pay him to be available to paint them (which increases the cost for the client).

Using this structure, the supplier generates a larger sale, because instead of man-hours, it sells man-months over long periods of time. However its role as a staffing agency is all the more emphasized, and because it’s commoditized and in high demand, prices must always keep going down.  

And here’s where your customer becomes your own competitor!  After a while the client will get offended by the obvious (the margin between the painter's salary and the end price of the butt-month) and determines to hire the painter himself, pay him more, and get greater value by saving on the profit margin of managing a worker himself. Butt-months only postpone death. In the long run, it's always the same man-hour.  

A results painter keeps looking for better ways to paint, better ways to pay, and keeps using trial and error in his search for the best and most efficient way to paint houses.

In short, results painters invest more time and money in the sales process by clearly defining what needs to be done, committing to a final cost, taking responsibility for estimation and execution errors as well as triumphs in case of achieving the result in less time and cost.  

By controlling the method and service from start to finish they have room to invent new ways of doing things, to take care of work culture and have their own organizational practices. They’re independent.  And lastly they have the greatest wealth of all: they can hire the most exceptional people given that they have room for a broad salary scale.

Butt-hour painters don’t have to invest a lot of time and money in preparing a price quote, because they don’t sell solutions to problems, they just rent time from their staff.  They don’t commit to a final cost because they only control a part of the solution. They promote cheap unit value distracting from the global perspective of the number of hours required.  For them, innovating is suicide, because doing things faster would mean selling less.  On top of that they end up with a large team of mediocre talent because there’s no financial capacity to pay exceptional employees on differentiated salary scales.

After seeing that in our country the large percentage of transactions in technology services is butt-hours or months, all I can say is that this is clear evidence of the triumph of the purchasing department over the general management, where the small picture wins out over the big picture. Because it’s obvious that the best bargain is not achieved by hiring the cheapest man-hour. You get the best bargain when you understand that it depends on the total hours spent, hidden costs, and the hours wasted sitting on butts.

General managers have been defeated by the buyers within their own organization, because although they know this, they still don’t realize that butt-hours and months means turning your client into a shareholder who has more control than you do. This doesn’t bring in any more income and takes away your freedom to do your job the best way you know how.  

For the supplier, this means playing a game that in the short term may bring growth and profit, but in the long run is unsustainable and creates minimal value. This is a game where we become nothing more than staffing agencies.

What happened at the end of the month or at the end of the year with the accounting of that money? I don’t know. Possibly the owner replenished it or entered it as a "miscellaneous" expense. In any case, I always thought this was rather strange. In the best of situations it made me think that this company was run like a mom-and-pop shop.

During my work supporting various companies and my own experience as an entrepreneur, I’ve identified two main groups of entrepreneurs:

• The Shopkeepers, where there are only one or two partners who work most of the time in the company.And the

• Meticulous Managers. These are the ones who have three or more main partners, plus external partners who don’t work at the company.

This arbitrary classification makes it possible to group outright divergent behaviors in cash management, accounting and, consequently, taxes.

Shopkeepers tend to record all sorts of personal expenses as company expenses, such as: lunches outside the business, transport for activities not related to corporate purpose, salary of non-working relatives, vehicle credits or properties that are not related to commercial activity.

In general, sole owners of a business who in turn work for their own company, consider it redundant or unnecessary to pay themselves wages and then pay their personal expenses from them.

Meticulous Managers, on the other hand, have a defined salary or payment of fees that is paid on a fixed month-to-month basis. They rigorously separate personal expenses from those of the company. They pay said expenses from their own salary, and gradually develop expense reimbursement policies that become increasingly strict (budget ceilings, associated payments - taxes, deductions, social security, etc.).

I guess these people aren’t meticulous as a rule, but because they have to be. As many partners work, very likely only one or two have the authority to spend company money, and they can’t set a bad example for others. Additionally, if there are external and/or minority partners, they’re forced to act more transparently so that they don’t affect their partner’s assets.

Using company money for personal expenses is not merely a distinction that sets one group apart from the other: it’s morally reprehensible behavior, a violation of the law. That’s not the proper way to do things.

In the Colombian Tax Code, Article 107, it’s indicated that expenses that are deductible from income must comply, among many others [1,2,4,5,6], with three basic principles [3]:

1. Causality: The expenditure must be related to the income-producing activity [6],

2. Necessity: The expenditure must be indispensable according to the commercial customs of the income-producing activity,

3. Proportionality: Expenditure must be reasonably proportionate to the income or the potential revenue-generating income.

In this sense, and in order to fully comply with the law, collecting receipts from a cousin’s gas tank or the lunch bill of a third party outside the company and incorporating them as a company expense is a violation of the principle of causality.

Paying interest on personal property such as vehicles or homes, without this having anything to do with the corporate purpose of the business, also violates the principle of necessity.

Likewise, paying the manager’s aunt and uncle the same amount as the manager when they don’t even work for the company, is a disproportion according to the commercial customs of any sector.

These are all gimmicks used by unscrupulous accountants and tax reviewers to reduce taxes, but that go against good conduct and defined laws.

This situation then leads us to answer the following question: if I am the legal representative, general manager, and full owner of my company where I work all the time, why can’t I record my family’s groceries as a company expense?

The answer is simple: because you created a company that’s a legal entity independent of the natural person, and that is subject to different laws indicating tax principles that must be treated with the utmost respect.

Obviously if you want to have a mom-and-pop shop, a small, disorganized business that you’ll never be able to sell in the future, you can disobey the law and never even be found out. Now that you know that, if you keep doing it, you’ll just be a sneaky corporate fox.

If, on the other hand, you want to change these behaviors and be an exemplary entrepreneur, then you have to pay the price of doing things right.

Give yourself a salary. It doesn’t matter how much—that’s a capacity issue and not a legal one. Apply the corresponding withholdings, pay the required social benefits, and by doing that, your salary will be tax-deductible. It’s causal, necessary and, I hope, proportional. You can sleep peacefully knowing you’re not stealing from the State. You’ll be running a business, not a shop.

1. Non-deductible costs and expenses.

2. Formal requirements for costs and expenses to be deductible.

3. National Tax Code – Article 107 – Necessary expenses are deductible.

4. National Tax Code – Article 618 – Obligation to demand an invoice.

5. National Tax Code – Article 617 – Requirements of the sales invoice.

6. Deductions must be causally related to income-producing activity, not income.

7. Concept 074532 of November 2, 2004.

Lawyers and accountants will often advise a person not to formalize until achieving a certain amount of cashflow or business deals that would cover the initial and recurring costs that formalizing implies. However, if you look deeper, nobody ever knows exactly what these costs are.

Let’s answer this question coherently by looking at financial statements and accounting records, and from these build a basic model of initial and minimum monthly expenses for a small business registered in Colombia. Consequently, this analysis is validated by the market, which means that for each spending component there exists a provider who, at the time of this publication, offers this service satisfactorily.

All expenses mentioned will be gross values: i.e., before taxes and deductions. The reason behind this is that taxes have to be paid whether you’re registered or not, so we don’t count them as a cost of registering.  The VAT collected must be returned at another time, therefore it is not an expense but simply deferred income. Income tax only applies if there are profits, and in any case it also applies to natural persons under certain circumstances.

The design criteria for our Simplest Business Entity (like a corporate MVP) will be as follows:

1. Minimum team: one (1) full-time partner

2. Laptops: supplied in kind by the partner

3. Wages: (see this article)

4. Work Culture: No teleworking, therefore leasing office space must be considered

5. Independence of partners: P.O. box, phone line, partnership

6. Partners experts in the product, though not in design, accounting or law

7. No favors liabilities: paying cash for required help

8. Economies of scale: annual or multi-item purchase orders from a key supplier

9. Target: marketing of a single clearly defined product or service

10. Rounding up: overestimating instead of underestimating costs in order to stick to the budget

11. Complying with all legal obligations in a timely manner

We invite readers to challenge all costs and concepts in this article. If a reader of this blog considers that an expense

• is not mandatory,

• has a better,

• cheaper alternative or costs less than presented,

please explain your disagreement in the comments so that we can obtain a better consensus on the minimum cost of formally starting and operating a company in Colombia.

We’ll start by identifying all strictly mandatory expenses related to being registered.  K will be used to designate thousands, M to designate millions. If currency is not specified, it refers to COP. USD will be used for US dollars and for the conversion between currencies we will assume an exchange rate of $2,500 COP.

1. Articles of Association ($350K/one time): These are the constitution and definition of the purpose and basic governance of the new entity that is to be established.  They can initially be written with standard templates found online, but it’s prudent to hire an attorney to validate them at the end.  The lowest fee for this service is 1/2 Minimum Monthly Salary (MMS).

2. Constitution ($400K/one time): Chamber of Commerce and Dian (equivalent of IRS) registration procedures must be carried out for the new entity.

3. Accounting and Tax Services ($2.4M/year): To keep accounting records, record them in the information system, present financial statements and settle taxes and reports required by the DIAN (IRS), it is necessary to have an accountant. The value is estimated at $200K/month

4. Commercial Registration ($300K/year):  During each year of operation and regardless of incorporation date, all companies in Colombia that carry out commercial activities must maintain a record of existence.

5. Industry, Commerce and Notices Tax ($480K/year):  Depending on the municipality in which the company has its operations, the ICA must be paid.  This value changes with annual sales but is initially paid in Medellín at $40K/month.

6. Certificates of Existence and Legal Representation ($60K/year): Once the company exists, this document issued by the Chamber of Commerce with limited validity (2 to 3 months) becomes its identification.  It must therefore be obtained periodically, and we’ll estimate needing 12 updates per year with a cost of $5K/unit.

7. Fixed Financial Expenses ($720K/year): Once the business exists, a bank account is required, one (1) debit card for physically carrying out procedures ($10K/month), and a virtual branch with a user to be able to do work online ($50K/month). It should be noted that what is most needed as an entrepreneur is a low limit credit card in the company´s name, however this is impossible to obtain for a start-up company.  All of the above prices and restrictions are based on Bancolombia's policies.

8. Variable Financial Expenses ($150K/year): This refers to the fact that once a company begins to exist in the financial system it must begin to pay a series of commissions for using different services.  In the historical review of our supports, the best model to predict these expenses is as a percentage of total operating expenses and costs. That is, the value increases or decreases depending on what is spent as a company.

   The suggested model is to estimate between 0.5% and 1% of period operating expenses for this point.  To calculate the annual value, we will assume an average value of 0.75% with annual operating expenses of $20M.  This point breaks down as follows:

   • Tax on financial movement: 4 out of every 1000 pesos transferred

   • Third Party Payment Fee: $2,500 COP for each payment made

   • Interbank transfer fee: $14,000 COP for each payment made

   • Fee per email sent: $200 COP for each email sent

   • Interest credit in savings account: <6% per annum on the balance

Taking the aforementioned points, a small company would have initial mandatory expenses of $750K ($0.8M) and annual recurring ones of $4.110K ($4M), therefore, monthly recurring expenses of $342K ($0.3M), for a total investment of $4,860K ($5M).

The previous section is the minimum cost of existence, however at the beginning, investment in other minimum items not mandatory to formalization is also required.  Below are those we consider to be in this category:

1. Brand Design ($1M/once): Most companies are created to market a product or service.  This is marketed by positioning a brand in the mind of the consumer.  Creating the brand means defining the audience, the message to convey and with it, basic graphic elements: logo, slogan, fonts, colors, templates for slides and for documents, etc.  This is an initial cost and from this other graphic elements can be derived quickly and inexpensively.

2. Landing design ($1M/once): At the beginning of this MVP company, creating a website--in addition to being slow and expensive--can be useless.  Initially, a serious, simple, rapidly deployed Internet presence that serves as a sales and conversion channel rather than an informative site is what is needed.  To fulfill this purpose, designing a landing page is the best solution.

3. Landing Page Service ($1,620K/year): Prices of the two previous items can be achieved if a web designer is given a tool so that--without engineers—they can build a decent site for the customer in less than a week.  The landing page service costs $135K/month, and includes hosting, statistics, A/B testing and can be modified in minutes by the entrepreneur without needing HTML knowledge.

4. Basic Communications Expenses ($460K/year): The most basic cellphone plan costs $35K/month, and a P.O. box $40K/year.  These two items allow the company to have a point of contact which is independent of its partners (no registering mom´s address in the company's RUT) and minimizes changes in contact info for the international world.

5. Location Expenses ($1.8M/year): Cubicles in co-working spaces or in nearby companies can be obtained for $150K/month per spot.  This includes chair, work desk, electricity, telephone, shared wireless Internet and possibly, access to some meeting rooms. Although it seems like a good option, our philosophy is that we are against teleworking, therefore it is presented as a minimum non-compulsory expense.

6. Domain registration ($150K/year): Every company has a domain that represents its brand on the Internet.  Unless you want to call yourself Coca Cola, the annual cost of the domain and its anti-spam protections for contact information is $150K/year.

7. Communications Services ($125K/year):  Lastly, email, calendar, chat, forms, online document editing and file sharing are required in order to be in touch with the world and market services.  Each Google Account costs $50 USD/year.

Consolidating the above, we now have minimum initial non-compulsory expenses of $2M, annual $4,155K ($4M), that is, monthly payments of $346K ($0.3M), for a total investment of $6,155K ($6M).

It’s important to note that of the $346K/month, $160K/month correspond to cubicle and communications expenses for each person.  That is, the highest and most significantly rising investment goes to work culture (not teleworking).  If, instead of one person, we have a team of three, the minimum monthly non-compulsory expenses practically double:$667K/month (92% more than the minimum). On the other hand, if the only person in the company decides to work at home, the $346K/month decreases to $192K/month (56% less than the minimum). In this category, work culture is actually the relevant discussion.

Therefore, adding the two groups of previous expenses--mandatory and non-compulsory--starting a small company requires $2,750K ($2.8M) initially and $8265K ($8M) annually, plus $1,920K ($1.9M) per additional person. That is, monthly payments of $689K ($0.7M) plus $160K per additional person, for a total capital requirement for a one person company of $11,015K ($11M). $13M if there are two people.

If you need to formally register a business, you must understand that no less than $5M of investment or income is required just to pay the corresponding registration, without accruing or investing a penny in other aspects of the business, and additionally between $6M and $8M are required for some minimum but not mandatory aspects.

To determine the annual sales we need to expect in order to make registration worth it and be able to cover costs while leaving a minimum of profitability, let’s carry out a comparative analysis of Colombian companies with sales of less than $200M/year and with a net profit between 5% and 10%. In this way we only analyze actual registered businesses and not registered subsistence businesses that don’t generate surplus capital.

The proportion of administrative expenditure above revenue is between 10 and 20%.  This ratio is 20-30% for sales expenses.  In other words, on a consolidated basis, operating expenses without cost of production or goods fluctuate between 30 and 50%.  Clearly these values include the labor component, which is usually the most important.

Based on this analysis we suggest that to maintain returns which are comparable and competitive to industries of the same size, registration expenses need to be between 5 and 10% of sales. Considering the $5M necessary for registration, annual sales must be between $50M and $100M.

To place these values in perspective in a small company, and considering the cost of labor, we discover that a company with an annual income of $100M is equivalent to a natural person with a monthly income of $8M or one who receives $6M from a labor contract.

I believe that after the financial exercise and knowing the reference ranges for registration, many questions arise as to why you want to formalize: to gain access to Chamber of Commerce benefits? Access to income tax benefits for startups? To abide by the law?

The final conclusion is that registration makes little immediate financial sense. It’s purely overload. All the good things you can do as a registered formal business you can also do as a natural person, such as keeping accounts or paying taxes properly. However, these are the two structural reasons to register despite the extra cost:

1. It groups risk-sharing into a single entity: This applies when there is more than one partner and allows profits as well as risks (lawsuits and losses) to be distributed in a single entity and in proportion to the risk. If not formalized, the invoicing and contracting partner will have full control on paper over profits and claims in which the company may incur.

2. It generates trust for market interaction: For investors it’s different to invest in a legal entity than in a service belonging to a natural person. For the government it’s essential that companies be more than two years old in order to grant promotional resources; for some customers doing business with companies is more suitable than doing business with natural persons; for attracting talent it’s different to be hired by a company than by a person.

In short, don’t formalize if:

• You are a single partner

• You are not expecting to receive investments

• You are not expecting to receive government resources

• You are willing to sacrifice some customers

• You do not need to attract new employees

Otherwise, invest approximately $5M/year to have access to investors, promotional resources, all types of clients, and to improve your position for hiring staff. Additionally, seek to invoice between $50M and $100M during the first year to make sure you stay in good corporate shape.

This article is mainly geared towards roles that are essentially computer jobs within the context of an employee working for a company, who in turn participates in a market governed by perfect competition with fixed wage layouts.

My main objective in using these rigorous tracking systems has always been to obtain as objective a view as possible of the resources that are actually invested in carrying out a specific task.  Everything centers around this point: understanding reality as accurately as possible.  Any obstacle that stands in the way of this goal must be eliminated.

Objective tracking serves a higher purpose, a long-term application, and that is to enable a sound platform for rational and fair decision-making. It does not seek to maximize productivity, nor minimize the consumption of resources, nor supervise, nor pressure; it seeks only the first goal: to objectively evaluate reality so that subsequent decisions on estimation, allocation, remuneration, rest, relocation and prices will be tenable and fair.

When it comes to implementing accurate time-reporting systems, the biggest obstacle is theself-perception of hard work.  Human beings always tend to think they work judiciously and more than others.  Therefore, when time-reporting systems are based on arbitrary judgments of how long you think it’s taken you to perform a certain task, you inevitably report more time than was actually spent. Humans tend to overestimate themselves, and the perception of their effort is no exception. For this reason, the first step towards accuracy is for work time to be reported automatically.

Systems that allow this do so through timers, mouse supervision, keyboard and screen monitoring, downtime alerts, and website classification, allowing for an accurate view of time use in computer-intensive work.  

The main objection to this is based on invasion of privacy. However, as long as users are given the option to interrupt tracking whenever they wish to take breaks for personal activities, it is nothing of the sort. With this feature, privacy is maximized, time tracking is accurate and users are given control to work at their own pace without affecting actual work time.

Another classic objection stems from the new generations’ insistence on their capacity to multitask. That is, to work and not work at the same time (because only working is out of the question).

People who pride themselves on having the ability to multitask should contribute to global productivity by becoming research subjects at a laboratory! To date, research in human behavior demonstrates these multitaskers would be the exception and not the rule since the brain is only able to perform one intelligent task at a time. Also, additional initial loading time or post-interruption time is required. The only additional activities that can be performed flawlessly at the same time are things as mechanical as breathing.

That is, either you’re a scientific anomaly worthy of experimentation that has the ability to perform two intelligent activities at once, or actually your job consists of performing one intelligent activity and several mechanical ones.  If you want to read blogs, chat, watch videos, or gossip on Facebook, go ahead: pause your work and concentrate on an active break that gives real rest. If, on the other hand, you really can do several intelligent things simultaneously, you can use these tracking systems to demonstrate your supernatural productivity and be rewarded accordingly.

In this style of time tracking it is important to clarify two concepts from a measurement point of view: Potential Work Time and True Work Time.  Potential Work Time is the amount of work time established on an employee contract.  In Colombia the maximum work time is 48 hours per week. This refers to how much time an employee commits to in exchange for pay. However, there is a cultural consensus and tacit agreement that this time is more of a range of employee availability than an actual work requirement.

For this we need to understand the concept of True Work Time: percentage of potential work time that an employee actually dedicates to a particular task (client, project, etc.).  During 2013 and 2014, data was collected and analyzed on a Colombian engineering team of 30 people, who used and still use automatic time tracking systems without explicit True Work Time requirements. It was found that the employees who manage personnel, projects and administrative functions had a True Work Time range of 90% to 100%.  

Engineers, on the other hand, in the vast majority of cases, ranged from 60% to 80% of True Work Time.  This shows that the type of work has a direct influence on True Work Time, and that 100% of True Work Time in some tasks is feasible, whereas over-exertion is totally out of the ordinary.

This point indicates another crucial aspect of my time management philosophy: no time quotas.  Having a total time report goal only leads to useless input and therefore actually hinders us from our objective of perceiving reality as it is.  There is no such thing as a True Work Time goal. People should not be told to report X time a day, Y time a month or estimate Z time total. Instead, people should be told to report reality and leave it up to each person’s conscience to use their Potential Work Time wisely.

When you set a quota, Parkinson’s Law comes into effect: work will expand to fill the time allotted for its completion. The capacity of an employee to achieve a task in less time is absolutely nullified. Managers naturally want to see Potential Work Time utilized 100% in all roles, but this is simply impossible. People need breaks, some more than others. People have different work rhythms. Our duty as managers is simply to observe what happens to ensure that everything is within reason.

Reasonable and recommended margins for deeper analysis of True Work Time are anywhere between 70% and 90%.  In a 48-hour work week, 70% of True Work Time is equivalent to 6.6 working hours per day for 5 days. In other words, a 33-hour workweek. This is a more accurate reflection of reality, and is actually lower than successful model countries like Australia who have a 38-hour workweek.  

On the other hand, reporting times of over 90% could be a warning sign that the person allows no space for informal interaction with peers, or a sign of voluntary over-exertion that could lead to burnout. If you notice someone working too much, your attention is required as well, if the company wishes to retain this employee in the long run.

Here it’s important to mention that we are human beings and not machines, and therefore any analysis of True Work Time on a specific day or week would be wrong. As humans we have irregular True Work Times. For this reason I recommend calculating trends using a rolling average, where each day you analyze for example the previous 20 days: simply add the previous day and subtract the first day of the period.  With this method you can always view a long period of Potential Work Time and True Work Time, making daily decisions based on relevant data samples.

The most common question that comes up when using these systems is, What is reportable and what isn’t?  Answers are derived from the most basic principle related to our initial goal: If it’s work-related it’s always reportable, regardless of whether it’s requested or not.  

For example, it’s reasonable for a person who is formally studying a topic of interest to the organization to report that time as training time. Likewise, time spent on commuting between cities and three or more commutes in a single day (the first two distances are equivalent to going to and from the office) is taken into account.

At this point we can see that in some situations, manual reporting is the only option, since during such times as work lunches, phone calls, travel, meetings or conferences the computer is not available.  With this in mind, it is perfectly possible to report times manually, and it is imperative to do so in order to be able to assign them to the corresponding cost centers.  For this situation, the recommended control derived from the aforementioned data analysis is to group employees into one of two possible role categories: highly and moderately computer intensive.  The first are the engineers themselves, the second being administrative and commercial staff whose roles contain extensive human interaction.  

To allow detailed individual analysis my suggestion of ranges at which to be alerted would be these:  For an employee in a highly computer intensive role, manual reports of more than 20% of True Work Time; for an employee in a moderately computer intensive role, manual reports for more than 50% True Work Time would be cause for concern.

Regarding this suggestion, once the alerted range is reached, I say that at no time is an employee’s True Work Time to be questioned, because there’s always the possibility that the employee is working while the reporting system is not in use. Only conversations over two or more months can lead to the conclusion that there are real problems with how this employee manages their time, and what critical decisions must be made regarding their relationship to the company.

In the event that an employee’s True Work Time exceeds 100%, I recommend redistributing responsibilities, extending delivery deadlines and immediately allocating compensatory time off.  If an employee report shows less than 70% of True Work Time, and investigation proves it reflects reality and not simply a reporting flaw, increase the level of assignments or shorten delivery deadlines.

Note that this is never about simply reporting more; it is about verifying whether or not the reporting tool is being used properly, and then reducing or increasing the person’s workload so that a fair balance is achieved for the whole team.

This goal seeks precisely to make the salary the only thing that differentiates some hours from others, and not that salary and generalized idle time make the distinction between the more and less productive people.

Time-tracking critics’ main argument is to say that not all hours are created equal, and that one person can accomplish in one hour what another person would do in eight.

Paradoxically, I absolutely agree. I believe that everyone’s outcome is different, and that this difference in value should be rewarded by salary, and not by idle time.  

If we look carefully at the following scenario posed by “high achievers”, we will see just how important objective time reporting is.

Orozco Hare earns $2M COP per month. He can easily accomplish Task A in just 2 hours, but takes a full 8-hour workday to do so.  Jaramillo Tortoise earns $1M COP per month. It takes her 4 hours to perform Task A. The remaining 4 hours of the day she performs additional Type A tasks.

When analyzing productivity, one might say that Hare is twice as productive as Tortoise.  However, if we incorporate the concept of salary and True Work Time, we realize that the Hare required 1/20th of a salary (one full day out of the 20 working days of the month: 2 hours working and 6 hours idling) to do Task A, equivalent to a productivity of $100K COP per Type A task.

Meanwhile, Tortoise required 1/40th of a salary to perform Task A, because although she spent twice as much time as Hare, she corrected the situation by using her Potential Work Time 100%, thereby rendering a productivity of $25K per Type A tasks.  

In short, not all hours are created equal, and this is reflected by the salary. To maintain wage equity it is imperative to maintain a relative standard of True Work Time throughout the team, both to control excess (over-exertion) and deficit (idleness).

In the previous example, assuming both Hare and Tortoise were to perform their jobs with equal quality, their salaries are perfectly balanced and fair. Hare, who is twice as productive, makes twice as much as Tortoise.

But when True Work Time differs, the situation deteriorates to the point that the true total productivity of Tortoise is 4 times more than Hare’s, and she’s getting paid half as much. In other words, giving someone who works 20% of their time the same wage as someone who works 80% of their time not only generates a negative impact on the team but also creates a real problem of unequal pay.

Another common objection to time reporting relates to the use of measurement systems by goals or results and not by resources used.  Once again, I completely agree with this objection. I simply believe that it’s inconsistent within the framework of contract type.  

In other words, you can’t profess to be “measured” by results, something that is typical of a service contract, and at the same time have an employment contract where results are out of reach.  Therefore, I agree that a person does not have to report time when the contract governing the employment relationship is based on fulfillment of a clear and defined result.

The easiest example to use here is that of a business person.  If a person has a clearly defined role with an explicit mission—such as the marketing of Software Z—and their compensation is defined as 10% of collected sales, obviously the time spent is inconsequential, since their productivity is embedded in and controlled by the compensation.  

Additionally, in this framework, the risk of unproductivity or failure to achieve results is transferred from the investor to the worker, therefore the administrative control function is incorporated.  It’s absurd, then, to expect:

1. steady compensation,

2. variable or unknown work time and

3. measurement by results where non-compliance makes no difference.

Expecting steady income without investing resources or taking risks is unheard of even for the most sophisticated of investors with preferential shares.

Once the concept of time reporting is overcome, another aspect of infinite discussion is the granularity of it, that is, to which object do I report the time I am working.  The possibilities are innumerable as I can report to an activity, a deliverable, a milestone, a project, a service, a client, etc.  

Here the recommendation is to start with the largest possible level so that all times can be grouped and mathematical operations with said data can be performed.  It is useless to report to activities and/or deliverables if all efforts of several people on the same grouping object are not later analyzed.  The best way to implement this is to start with reports to a project or customer independent of the activity or to the deliverable of the same. In this way you can always unite all efforts and intersect corresponding revenues to build profitability.  

In those internal activities where the client is unknown and therefore has no associated income, the best thing is to report to first level profit and loss accounts so that times can be multiplexed to allocate precise costs to corresponding accounts: operational sales expenses and operational administration expenses.

Automated objective time-reporting systems are the basis for maintaining an equal-pay-based, healthy work culture, built on facts and objectivity and not the whims or perceptions of a manager, when

1. They are clear on the agreed-upon Potential Work Time.

2. They understand that we are all human and we’re available during said time but we only work for part of it.

3. They use a rolling average to get an accurate trend of behavior, which, as always with humans, will be irregular.

4. They stem from good faith (assuming first that an issue is due to underreporting and not underworking).

5. They are uneven in the relationship between employee and company, compensating over-exertion and neutral towards absenteeism.

In short, automatic time-tracking systems do the following:

1. They do not seek to make us work all the time, they seek to make us work fairly.

2. They do not seek to supervise, they seek simply to learn how much work is actually done.

3. They seek for those who work excessively to have rest, and for those who work less than agreed upon to work reasonably.

4. They see to it that everyone has a similar True Work Time in which salary does make the difference, where people earn $1M and others earn $6M precisely because their performance in similar conditions is 6 times higher.

5. They seek to create a healthy and separate work/life balance, which is different from the idea that leading companies try to sell, where mixing work and personal environments seems to be the model to follow. This only leads to the invasion of family spaces, the perception of giving more than what is received or of working all the time in exchange for a great salary that consumes your life.

6. They seek to objectively evaluate the resources a person spends in accordance with the nature of the employer and employee contract, since compensation for results, although a possible scenario, must be associated with well-defined and permanent results in the labor relationship, an issue that in the knowledge industry is utopic.

In short, it’s not about working smarter instead of harder, but rather working reasonably and fairly, so that smart work will make a tangible difference to all sides.

Throughout my career, I’ve run the gamut of being a member of the audience, a guest speaker, on the panel of judges, an investor, and an advisor, and I’ve heard countless pitches by entrepreneurs where I can’t figure out whether they’re looking for investment or conducting an experiment in defending the absurd.

In the two to three years of attentive listening and rigorous note-taking on presentations of entrepreneurs, I’ve developed a brief method to rapidly filter out those who pretentiously sell hot air from those who quietly take action.

The first and most important thing is to not let the entrepreneur start the pitch before you (the advisor or investor) first conduct a brief quantitative interview. It will take no more than 60 seconds and will give you the appropriate level of understanding of the relevance of the team you have in front of you:

1. How long ago was your startup formally constituted?

2. How many partners are there?

3. How many of them worked full-time last month?

4. In addition to these partners, how many other people worked full-time last month?

5. How many sales did you achieve in the last three months? Or, alternatively for product companies,

   1. How many active users did you have in the last month? and,

   2. How do you define an active user in the month?

After this short interview, the presentation can begin. Now the next 30 minutes can focus on structural issues and not on the sale of hot air, big ideas, large market sizes, scalability, iterations, etc.    

With this small I.D. badge that all entrepreneurs and presentations should have as their first slide, the time and efficiency of many businesses can be maximized.  Many potential entrepreneurs may likely receive more help if they start with a little humility, and the empathy that can grow by addressing core issues the rest of the time may be more worthwhile even than getting the investment.

Knowing when the idea was established gives you a picture of how seriously a founder believes in what they’re doing. Though age does not necessarily equal wisdom, in entrepreneurship it’s definitely a symptom of courage.

The number of additional full-time staff is a sign that there is already a consolidated team and probably income.  

Lastly, the sales or active users of the last month shows you if they are able to get to the market with a product that solves a real problem, or if you’re simply looking at a PowerPoint presentation on a business that doesn’t even have a prototype or that was validated by letter of intent (I don’t know who came up with that).

All the questions are designed so that their answers must be based on quantifiable facts of the past, therefore they are precise, short, concrete, and escape opinion and subjectivity.  If they don't know the answers, you have before you someone trying to sell you something that even they don’t understand.

By using this method I’ve been able to narrow down my conversations to only serious teams who’ve already taken the initial step that they must take for themselves.

It is completely naïve (and yet, quite common), to think that the investor or advisor will help you quit your job, create your company, and make the first sale—steps that only you, the entrepreneur, can take.  The entrepreneur is the only one who can save up, quit their job, sell the car or motorcycle, lower living expenses, and tighten their belt during the first years of working towards what they believe in.

It's also important to remember that at some point we all start from scratch, and that the answers to these questions must be brutally honest so that dialogue can continue on the same page.  The entrepreneur's badge is not discriminatory. It’s a baseline for the conversation to occur at the level that the venture is really at, and to receive the help, advice or money according to the capabilities and time of each team.

Below I will present what in my opinion are the most common characteristics of pseudo-entrepreneurs who today ardently seek funding in these investor meetings and the reasons why they sometimes generate distaste:

1. Weakly constituted teams: They’ve known each other for a short time; they all work remotely, they’ve never actually worked together; they’re a group of friends who came up with the idea but only one of them actually does all the work; they lack the basic skills in sales, production and management required by a company.

2. Multiple simultaneous ideas: Absolute diversification of ideas, approaches, products, and segments, all in initial stages of the company; they have up to two and three divergent business lines with virtually no turnover or users.  Some go so far as to have several startups running simultaneously. The idea of do-over has given them an excuse not to persist, and they don’t even have a firm conviction that something can work.

3. Minimal dedication: They work simultaneously in another company; they work part time; they work flexible hours, or even worse, they consider that tracking work time is slavery and not a way to understand costs, maintain fairness and objectively promote the only way in which results can be achieved sustainably: effort and sweat, not ideas.

4. Astronomical money requirements:  The de facto standard for a pitch to a venture capitalist or an angel investor is to ask for $1M USD for software development, advertising, equipment, offices, salaries, and patents.  The founders seem to think that having passed the screening process gives them carte blanche to ask for these sums and be treated seriously. However, I find it vulgar to ask for such elevated sums of money when the arguments that support it are mere speculations.

   1. To illustrate how ludicrous this is, of the 420 technology companies in Colombia (ISIC codes K7210, K7220, K7230, K7240, K7250. K7290) only 20 achieved earnings after tax above $1M USD (data from 2013, with the dollar calculated at $2,700 COP) and their average is $5.5M USD. If we discount IBM, which is a singular anomaly at the top of the list, the average drops to $4.2M USD.  That is, you’re asking between 20% and 25% of the yearly profits of the TOP 20 Companies in Colombia, or half or more than the profits the remaining top 400 companies make in a whole year.  In short, what they ask is ludicrous not only because it’s a lot, but because investors with an origin in IT are actually quite poor. The place to ask for those figures is Silicon Valley, oil companies, banks or mega constructors who may not have smart capital.

I believe that every entrepreneur should be made to wear an I.D. badge at these social events. Just as rappers were distinguished by their baggy pants or skateboarders by their jeans dragging on the floor, every self-proclaimed entrepreneur should wear a badge with large, visible data about his company. He should wear several badges if he’s had several startups.

That way the truly remarkable people would stand out and we’d know who to go learn from, while the future-Mark-Zuckerberg big talkers would realize they need to shut up and listen more.

If nothing else, this I.D. badge would give context to know exactly who’s talking. We’d know if this highfalutin “Emissary of Entrepreneurship” is speaking from the shoulders of academics, or from the bloody hands and scraped knees of experience and results.

The first reason a company may decide to establish a variable pay plan is a fervent desire to incentivize its employees to work in the right direction, and so they hope to positively reinforce this behavior with money. 

Another possibility is, if their base income is already at market rate, the administrators may want to share with their team the wealth generated in the process.

Or lastly, if an employee’s base income does not correspond to the market salary, the shareholder is simply sharing their own risk with the employee by assigning a market salary with variations according to performance.  

Throughout this article, we will show how the noble intentions of the first two reasons doesn’t make them any less useless.  We won’t discuss the third reason, because if you decide to stay in that job, maybe your market salary is not what you think it is.

When you start these kinds of policies, just like with teleworking, people receive it happily. Especially because in the initial stages of implementation the variable is an additional salary component that they didn’t have before, and it brings with it the possibility of getting more income, regardless of the difficulty this may imply.  At worst, they’ll say: 'I didn’t have it anyway, so if I don’t earn it, it’s not like I lost anything'.

In short, variable pay will always be accepted at the beginning, unless the variable is implemented as a measure of salary reduction, which is another topic that we won’t discuss here. If you sign on to something like that it’s because there was no other option, and most likely the total benefits you were already receiving were above the market.

The first of the big dilemmas that appears with the definition of variable pay is about what kind of goals will be rewarded.  

On the deepest philosophical level, an organization is a team, and in this sense, compensation should be associated with the team’s overall performance (as in winning the tournament, in a football context). So bonuses, etc., should only be given if the company surpasses its profit goals. Granting incentives simply to meet the profit goal will increase spending, undermine profit, and put the company at risk.  

However, compensating based on overall company performance creates new problems:

• Profit is measured annually, therefore it must be paid annually. So the carrot is so far away that it doesn’t incentivize, overriding the original intention.

• Will anyone be truly incentivized to pursue the overarching goal of company performance when they know that their individual actions will have a minimal impact? The success of the company as a whole is the most logical goal to reward, and yet it ends up being a minimal motivator.

So if aiming for overall group goals doesn’t seem to work, we can look for an easier incentive: individual goals. They’re a “carrot” that is easier to identify and determine. And since they correspond to just one part of the company’s process (sales, expense reduction, etc.), they can be awarded over shorter timespans (quarterly, monthly).

Individual goals are a powerful carrot, for better or for worse. In football it’s the equivalent of giving bonuses to the one who scores the most goals. This does not necessarily honor the collective game or passing the ball to a teammate who can score the goal, as we will see below.

The most common variable pay scenario is payment by commission: if you sell more, you earn more, if you sell less, you earn less.  It seems logical, but is utterly foolish, especially when it comes to intangibles.  

When you incentivize this behavior, a salesperson seeks to sell at all costs. They’ll sell to anybody, whether they’re a good customer or not. They’ll convince the customer to buy things they don’t really need. Or they’ll sell at a loss and not care, because they’re going to change companies soon anyway.  Budgeting goals are no different: is buying cheaper buying better? Does buying less generate profit, or does it generate supply problems?

Some expert in compensation models will say:  "That’s why you need to have variable pay proportions for group goals and individual goals."  

That doesn’t solve the problem, in fact it just changes its magnitude.  From a human standpoint you’ll still think: "On group goals my influence is minimal, so I’ll seek to achieve individual goals regardless of the immediate and future impacts I have on the company".  It’s understandable, in the end: if all you measure and reward is sales, humans will behave accordingly.

Additional questions that arise regarding variable pay are:

• Does money actually incentivize quality, or even incentivize at all?

• Can people live decently on their base income and use compensation only as a surplus, or would the absence of these bonuses gravely impact their livelihood?

• Is it easier to overcome an economic crisis with a team who had no additional compensation to begin with, or with a team who systematically loses the compensation they’d come to expect?

• Variable pay is meant to incentivize, but in the long run does the novelty wear off? In the end does it actually do the opposite and cause discouragement when the incentive is not achieved?

• Does a manager really know the secret formula of balancing individual and group goals so as to lead to the fulfillment of the global strategy?

• How do exceptional employees feel when they start getting paid extra for doing what they normally would already do?

The message that gets conveyed by rewarding achievements with money is that things must be done for money and not because they’re the right thing to do.

In short, I believe that the relationship of an employee with the organization for which they work must be marked by a prior agreement in which there is a fixed salary according to the market rate as an exchange for the time that this person dedicates to the organization.  

Paying based on the results of the company technically means transferring some of the risk to the employee. If transferred for profit, it should be transferred for loss as well.  

Incorporating variable payment models stimulates selfishness in individuals. On a group level, variable pay increases the cost of the company without motivating the majority, and demotivating when it’s not won.  People need to be incentivized by the task itself. They should receive motivation from a fair environment that favors their development, and want to do things well because they understand their importance.

We need salespeople who can understand the customer and be able to say: "You don't need what I have, you don't have to buy from me.” We must have staff who love what they do, and who do things right because that’s the way to do them. In order to do this, our expectations have to be focused on doing things right, not just on making more money.  

In the end, Enron collapsed for wanting to meet the goal and earn the bonus, and for this purpose companies were created to hide losses. How does this differ from what your purchasing staff may be doing with your suppliers today, or what your sellers may be doing with customers in order to earn the bonus?  

As in the Enron case, you will notice too late.  If there’s a bonus to be paid, it should be given years after the actions taken, since the full and true impact of actions can only be seen with the passage of time.

1. An employee who currently earns $2 million Colombian Pesos (COP) in Company A and is getting ready to start their own Business B, must understand that the cost of being paid in their new company is not just $2M COP for 12 months.

2. Paying $2M COP under a service agreement is not the same as paying a $2M COP salary or comprehensive contract.

3. New startup companies in Colombia need to know what social benefits or payroll taxes they have to pay for every $1M COP they pay in salary.

4. Not all salary ranges have the same tax burden or workload.

5. It’s common for new entrepreneurs to calculate the price of services based on what they’re currently getting in cash, when at the very least they need to calculate costs and pricing using the final total cost they had in their last job (even if they don’t get paid that amount in cash).

6. When you want to standardize salaries in order to compare wage scales, the best way to do this is with the total cost.

Taking these issues into consideration, I created a model to know the respective total cost multiplier for different salary ranges and according to current law (2015). Over the past six months, several managers in different companies have successfully tested this model multiple times. However, it goes without saying that I’m not an accountant, nor a lawyer, nor an actuary, nor an economist, nor an administrator.  I'm just a systems engineer who's keen on getting things right and using the highest precision at the right time.

The model is built using the following assumptions: indefinite term labor contracts, fixed wages, no overtime, paying all legal obligations in a timely manner, only considering labor costs (not those that scale with it – like laptops, work area, furniture, access accounts, etc.), a company without any type of extra-legal benefits (medical insurance, etc.), and assuming that taxes are paid on 100% of the salary, we have the following:

• $644,336 COP (1 Monthly Minimum Wage, or MMW) has a total cost of 1.75X if the company does not pay the CREE tax,

• $644,336 COP (1-2 MMW) has a total cost of 1.62X if the company does pay the CREE tax,

• $1,288,673 COP (> 2  and < 10 MMW)  brings a total cost of 1.40X,

• $6,443,360 COP (>= 10  MMW) the total cost is 1.53X,

• $8,376,368 COP (>= 13 MMW) if it’s total compensation and not base salary, the total cost is 1.27X,

With these multipliers you can calculate the total annual cost to the employer of paying yourself or hiring labor.  For example, if you are offered a service agreement, you can use the multiplier as a divider to find the equivalent employment contract that you are being offered.

Recently Colciencias offered salaries of $6M COP per month to high-level researchers to come from prestigious universities around the world.  Many researchers accepted that offer.

Let's do the respective analysis.  Due to the < $8M range, these wages are not total compensation, therefore the multiplier is 1.53X.  The total annual cost of a senior researcher for a university would be $6Mx1.53 ×12=$110M/year.

We can also analyze how much money a researcher of this caliber would lose if Colciencias or the universities decided to change these $6M from a labor contract to a service agreement.  $6M ÷ 1.53=$3.92M, would be the equivalent of earning $4M per month on a labor contract.

These multipliers also imply that in the region of a $10M COP salary, not all that glitters is gold. It’s fundamental to know if payment is total compensation or base salary, because if it’s total compensation then it’s $10M ÷ 1.27X, which is equivalent to $7.8M in a labor contract, a substantial difference.

It also implies that if you earn $6,952,932 COP on an employment contract, you can propose to your employer to change to a total minimum compensation of $8,376,368 COP and improve your cash flow without affecting the profits and loss of the company you’re in.  

The staggered intervals also show possible optimizations typical of these models: Paying 2 MMW or 2 MMW + 1 peso implies annual savings on labor obligations of $3.4M without affecting the cash flow or social benefits of the employee.

Finally, this model includes a small historical calculation of severance pay of 1.5% of salary, however it completely ignores other costs (such as SENA apprentices, approximately 1 apprentice of 1 MMW for every 15 employees), provisions for unrecognized disabilities and paid leave that requires replacement, transportation allowances, communications and telework (there’s still crazy people out there).  I’m open to hear improvements, so comments on this article aren’t just philosophical discussions anymore, they’re improvements to the model.

In 2001 the word “entrepreneur” didn’t even exist.  In ninth grade I met someone through IRC and together we fell head over heels for a revolution that fused technology with my rebellious teenage communism: Free Software, Linux, Slackware and lastly Debian.  When we got to university we thought: "Finally we’ll get to learn about Linux!". However, by the third semester we realized that colleagues, professors, and enterprises would turn to us when they needed help with this technology.  That’s when we said: 'Let’s start a company'.

We named it Fluidsignal, and we weren’t thinking about getting rich, selling the company, buying other companies, scalability, product, or innovation… we weren’t even thinking about next year's salary.  We just thought that we loved Linux and that apparently Linux helped people.  We also felt that after studying together for more than 4 years we were already a team.  However, we had no idea what we were getting into.

After 14 years of working as an entrepreneur, I can tell you from my limited perspective what entrepreneurship means.  I know that many entrepreneurs will agree with what I’m going to tell you; however, being an entrepreneur and talking about failure is a weird crossbreed that you won’t see that often.  They’ll approve my version silently, because sadly, failure in Colombia is considered something to hide, not something to learn from.

Simply and crudely, being an entrepreneur means sharing risk with a group of people. It means investing time and money into a cause that could work out or could go badly, so that when we win, we all win, and when we lose, we all lose.

Generally the cause does not go well, as Marcelo Bielsa would say: “We should make it clear to the majority that success is an exception. Humans from time to time triumph. But they usually strive, fight, struggle, and win only from time to time. Only from time to time.”

• Entrepreneurship is like pooling your money with several friends and betting that money playing dice, hoping to defeat statistics by spending some time analyzing the geometry of the dice and the style of the dice roller.  After several rolls, you’ve either won and want to keep playing, or you’ve lost and want to get your money back.  In the long run it's not winning that makes you stay, it's the team spirit you’ve created, or the love of the game.

• Entrepreneurship means working longer hours than an employee with a salary.

• Entrepreneurship means hiring people for a fixed salary at an indefinite term while all you have for a company is contracts for the next two months.

• Entrepreneurship means being the last to get paid.

• Entrepreneurship means paying yourself far below the market salary.

• Entrepreneurship means backing the company's credits with personal or family properties.

• Entrepreneurship means hiring your best friends and having to suspend or fire them and very possibly lose their friendship.

• Entrepreneurship means realizing that the market doesn’t want, doesn’t need, or can’t use your dream, and that you’ll have to change your dream in order to understand that the needs of others are more important.

• Entrepreneurship means realizing that there’s a tougher boss than the boss: the client!

• Entrepreneurship means getting personally into debt in order to keep a team going and hopefully recover what’s been lost.

• Entrepreneurship means winning and realizing that for some, no victory will ever be enough.

• Entrepreneurship has little to do with wealth, and a lot to do with sweat and relationships to people.

Today, entrepreneurs are like the rockstars of business. The press talks about them, Ruta N rewards them, and investors inject tons of money into them (or so it seems). However, the realities are harsher than those perceived from outside.  As my mother used to say, “You can’t believe half of what you hear.”

In most cases, entrepreneurs have negative equity. The number of users we hear about is registered users, not active or frequent users. Sales go up and profits go down. The luxuries you see from the outside are paid for on the credit card or by company money.  Nothing is as it seems.

After playing the game, you realize that the only thing invariant in entrepreneurship is the relationships you build with people, because as an entrepreneur you generally have greater control over these. You decide who to partner with, who to hire, who to lay off and who to sell to.  These relationships evolve to create bonds of trust, bonds that allow more complex projects to be developed.

To conclude, I want to focus on relationships with your partners, the closest and most infinite relationships you can have. Getting into a partnership is worse than marriage. When you’re married and you get bored, the worst that can happen is you pack your things and leave.  From then on you no longer see your spouse, you no longer have to talk to them, you go and live in your space and determine how to distribute two pieces of furniture and the expenses of the kids.  Having a partnership is worse:

1. Companies are a type of asset that is difficult to appraise.

2. Companies don’t only spend money, they also have income potential.

3. Dissolving a partnership impacts your customers and therefore your revenue.

4. In most cases the value of the companies is due to the people or partners in them.

5. The vision and values of the company are the intersection of your and your partners' values.

For all these reasons, added to the madness of entrepreneurship, I think that when someone invites you to be a partner in their company—that is, to pay you with equity instead of cash, that is, to pay you with risk!—you should feel insulted.  It’s marriage times ten! It’s like asking your hand in marriage without having met you, without having ever had a conversation or a fight, without knowing what you like, how you think, how you feel and how you behave in the good times or the bad times.

Today when someone tells me they’ll pay me with shares, equity, or risk, I feel insulted. However, I forgive them. They don’t know it means getting married times ten.

Have you ever wondered why someone would invite you to a business and pay you with equity? Are they unsure of what they can achieve on their own? Do they want to share wealth and poverty with you? Or do they just have no currency to pay you with other than risk?

But strangely, teleworking is a dangerous practice. It’s a temporary motivator that becomes breeding ground for laziness. It finances and incubates your competition or a new venture on the time of your clients' projects. Teleworking is a killer of work culture.

At first, teleworking looks like a timely solution to the transportation problems we face today, and to reduce office and equipment costs. It seems an efficient way to quickly incorporate talent from other locations, and an essential motivator for employees who aspire to work from wherever and whenever they want.

All these benefits are true and enjoyable during the implementation phase, making the company attractive to recruiting and retaining talent. But the truth is that once the Hawthorne Effect has passed, telework hinders communication, breaks down any sense of belonging, accelerates employee turnover and presents an impediment to teamwork.

Over five years ago I had the experience of participating in one of the first teleworking programs in Colombia. This company had 40 personnel at the time and used teleworking to scale up to a total of 50 people. The company sold its headquarters, tables, mugs, chairs, desks, technical equipment, servers… everything except laptops. All employees according to their performance were gradually allowed to work from home or wherever they wished, and stipends were granted for transportation, electricity and internet.

Everything seemed perfect. Employee satisfaction was at a record high according to the quarterly evaluations. People reported reduction of transport and clothing costs, more free time, and more closeness with their families. The company decreased its operating costs. Additionally, it could grow quickly and easily: all we had to do was lease new laptops and we were ready for more engineers.

The Hawthorne Effect lasted between 6 and 18 months. Only after many analyses and countermeasures did we see the damage and havoc that telework had caused.

• Training and education that was previously made easy by proximity to peers or the availability of other more experienced engineers became more challenging.

• Bringing about simple organizational changes that previously could be discussed internally and implemented in hours now took weeks.

• Divulging anything important now required tremendous coordination over meetings and teleconferences.

• Networking that used to come naturally now turned into mandatory meetings that created a burden on employees.

• New hires could never learn the corporate values and philosophies that can only be absorbed through observation or informal contact with peers.

• Some of the employees created parallel companies from which they provided services.

• Turnover times of staff recruited during the telework period were shorter than those who entered during normal periods.

• What once set us apart became nothing more than a commodity, aggravated by the fact that the company was now sluggish and had less sense of belonging.

Through this experience I learned the essential value of work culture. This is the kind of culture that emerges naturally through face-to-face interactions, team lunches and breakfasts, the teamwork that comes from knowing you can ask an expert just by getting up and going to talk to them, or noticing the expression on a colleague’s face and being able to ask “Are you ok? Is something wrong?"

Teleworking can work as an exceptional measure, but not as the radical solution that it’s being sold as today.  Some of these exceptional circumstances are:

• You’re a freelancer, therefore you are a solitary player who does not require expanding or creating workplace culture.

• Your company has individual, well-defined, highly standardized tasks that require low creative processes.

• People who have been in the company for a long time and know the culture and values well.

• Highly mature professionals, with years of professional experience and a solid well-developed work ethic.

• Specific instances, such as certain days of the week, illness or family circumstances (example, newborn children).

But under any other circumstance, for young companies, employees who are still developing their work ethic, recent hires, or knowledge industries, teleworking will kill all work culture.

This is a post-mortem experience gleaned from more than three years of trying to make telework survive—that’s how long we took to detect and correct the problem. It’s the experience of seeing other North American companies implement this strategy and experience the same situation.

When reading a blog post or an exceptional case of telework implementation, ask yourself: is this really a proven success story? Or is it an early victory by someone who's just starting? Are they the 30 best programmers in the world and therefore will be successful regardless of environment? Are they programmers with an average age over 35 and therefore have a highly defined work maturity?

As an individual it’s comfortable to work anywhere, and you can get individual tasks done faster.  However, while everyone may be faster individually, the company is slower.  It's like having Herbie at the end of the line.

If you’re still determined to implement a teleworking program anyway, know that dismantling it later it will be harder and way more painful than starting.  We had to repurchase office space, install reliable internet, change salary policies, and see a decrease in employee satisfaction. Not to mention that we lost valuable talent when some employees refused to return to the traditional system.

However, despite all this, we had no regrets. Today this company regained its work culture, decreased turnover, improved communication, and discipline once again became a respected value. And the force of everyone combined, rather than individual efforts, has kept it together.

We’ve discovered that secret by accident, and called it simply: receipts. Over time we learned that, as usual, someone else had discovered it first, and that it’s actually called Revenue Recognition or Services Provided according to international standards.

To explain this concept, we must understand that normal, orthodox invoicing reflects a fact that has already occurred, a service that has already been performed, or goods that have already been delivered. If, in your business, invoicing always occurs after the service has been provided, no problem. Your life is easy and you can stop reading right now and go watch TV.

If, on the other hand, your business has situations in which bills are left up to goodwill, or involve clients who want to spend their budget before consuming the product, or where, for reasons of cash flow or trust between parties, the supplier manages to invoice and collect payment in advance… this article could save your business.

Let’s imagine a company that registers income of $1B with a profit of $50M. In principle we could conclude that the company required $950M to produce $1B. However, the income statements that are recorded in the Chamber of Commerce and other control entities don’t account for whether those $1B actually correspond to revenue earned (goods delivered, projects completed, services provided, etc.) or to advanced billings unrelated to the $950M of costs and expenses.

To illustrate the problem, let's analyze a common situation, especially at year’s end, where clients have a surplus budget and want to spend it so as not to lose it the following year. They request that $100M of the aforementioned $1B be invoiced in advance, that is, $100M that will have no associated costs in the current year from the supplier's standpoint.

These $100M are not actually income: they’re a supplier’s liability towards the customer. However, since the State always charges tax on the highest amount in its favor, (more profit equaling more taxes), accountants don’t rigorously separate account balances and tax balances. And so the invoice gets recorded as income.

If we were to subtract those $100M of advance invoicing from the $1B of total income, we’d see that the services provided during that year were equivalent to $900M. Therefore, with costs of $950M, reality would show a loss of $50M. If the advance payments were $200M or $300M, we’d be talking about losses of $150M and $250M.

To an unsuspecting board member or a tax auditor unaware of the nature of the business, this situation might go unnoticed.  Years could go by showing the business breaking even or making a profit when there are actually colossal losses hidden by advance payments during the year-end quarter.

Fortunately, eliminating this problem is simple:

1. Always invoice a service already provided; that way you never record income that hasn’t yet been earned.

2. Use prepayment instead of advance billings. Technically, this is money a customer gives in advance without being invoiced and is therefore recorded in balance sheet accounts rather than an Income Statement.

3. Finally, the simplest option which maximizes cash flow and depends on no one else is the issue of management accounting for services provided.

   Management accounting for services provided allows you to know your actual output and benefits from actual costs. Simply assign an economic value to the real earnings you had that month, regardless of whether they were billed or not.

   For example, if 40% of a $100M project has been completed by the end of the first month, we will say that in that month you produced $40M of income.

4. In any case, try to maintain additional control from the cash flow, reserving any payment received in advance in a savings or trust account separate from the overhead account.  Some less drastic but not particularly better alternatives are reserving only corresponding costs, or costs plus operational expenses.  Either way, if you’re billing in advance, it’s likely because you need cash flow, so I doubt you will be strict enough to implement this last control.

To determine this value you can implement various strategies. The simplest is an inside end-of-the-month company meeting where progress of each project is determined and its economic value is found. A stricter one is to request the customer’s approval of said advance; here the matter avoids inside manipulation and also places the company at the customer’s service.

Once this process has been carried out you can add all the monthly income, subtracting monthly expenses and costs to determine if you are working with a company that is truly creating value or one where the financial phenomenon of advance payments and others cover over one hole by digging another that can’t yet be seen.

The ramifications of not taking this into account are endless. Imagine a company that by December 28th has rendered services for $1B COP with an actual net profit of $100M. A customer requests an invoice (including prepayment) for an additional $200M. This company will close the period with an income of $1.2B and $900M of expenses, showing a profit of $300M, giving rise to almost $100M in taxes. That is, it unnecessarily pays taxes on $200M of supposed profit when in reality costs of providing the service still must be spent, and, assuming they are similar to previous expenses, would come to $180M, for a profit of $20M. Advanced billing caused you to pay taxes on $200M instead of $20M.

Saying and repeating it is like stomping around the house shouting, "Let's use a hammer!" "Let's use a hammer!". 

Any unsuspecting visitor will only be left wondering: what do you need a hammer for? What's the problem? Do you need to hang up a picture? Remove a nail, maybe? Does the neighbor need it? 

Innovation is no more than a way to reach something, a tool to tackle a more concrete problem or pursue a more sublime goal.

Things get worse when this empty word is given nuances and categories. Incremental innovation, radical innovation, disruptive innovation… And of course, here the semantics geniuses get into endless philosophical debates, because some argue that only what is disruptive is innovation, that any minor innovation is not innovation at all. This debate is all the more useless when we don’t even know if we want to hang a picture or remove a nail.

Its meaning today contributes little to the world of entrepreneurship or work in general. Getting rid of it will pull us out from the spiral of semantics and philosophy and will make us focus on defining the problem and taking action. Any action, no matter how simple, cliché, or old-fashioned according to the theorists… if it solves the problem, it’s innovation.

So let’s stop saying innovation, and instead make it take on the meaning of taking action to change, modify, and improve.  Let’s focus on identifying the action that will lead us to our goal, outlining it in detail, making a plan, and carrying it out.

Just stop saying “innovation”.