How to Practice Entrepreneurship Inside a Company

How to Practice Entrepreneurship Inside a Company

Practice entrepreneurship inside a company by finding one bounded problem, securing authority to test it, preserving the organization's controls, measuring the completed workflow, and making the result legible to the people who must decide whether to stop, iterate, or scale.

Initiative is part of the method. Authorization is also part of the method.

The difference between an idea and a change

An employee close to the work often sees friction before an executive program does. The same document is rebuilt every week. Data is copied across systems. A specialist spends hours finding the few records that require judgment. A client waits while several teams reconcile different versions of the same fact.

Spotting the problem does not change the system.

A working prototype does not change the system either. It shows that one path might be possible under the conditions of the test.

The change becomes real when the organization understands the current workflow, authorizes the experiment, accepts the data and risk boundaries, sees evidence from actual users, and assigns ownership for what happens next.

Luke Tatman made a related distinction in Venture Step E081. He encouraged people in process-heavy roles to become more entrepreneurial, then Dalton clarified that entrepreneurship does not require leaving the company. A person can find a better way to work and build the case from inside an established firm.

1. Choose one job

Begin with a job a person or team performs repeatedly. Define the trigger, inputs, steps, output, recipient, decision, and completion condition.

"Use AI in underwriting" is not one job. "Extract defined fields from an approved document set and prepare a review queue for an authorized analyst" can be.

The scope should be small enough that a failure is containable and large enough that improvement matters.

The GOV.UK alpha guidance recommends testing the riskiest assumptions without prototyping an entire service. How the alpha phase works

That principle travels well. A smaller workflow makes the evidence easier to interpret and the risk easier to contain.

2. Establish the baseline

Measure the current process before proposing the improvement.

Record elapsed time from trigger to accepted result, active labor, queue time, error and rework rates, exception volume, handoffs, user friction, and any required control evidence. Use enough observations to understand normal variation.

Anecdotes can identify a problem. They cannot prove the size of the problem.

The baseline should include ugly work that a new tool may hide. If a draft is created in five minutes but a specialist spends two hours verifying it, the completed workflow did not take five minutes.

Quality needs an operational definition. It might mean field accuracy, decision consistency, correct citations, complete documentation, approved tone, or the absence of a critical error. The definition should exist before the new output appears.

3. Secure a sponsor and an owner

The sponsor provides the authority, resources, and organizational path for the test. The workflow owner understands the work and remains responsible for its operation.

They can be the same person in a small pilot. Their roles are still different.

The sponsor should know which problem is being tested, which systems and data are involved, what could go wrong, how participants are protected, how success will be evaluated, and who can stop the work.

An informal "go ahead" is not enough when the pilot touches confidential information, regulated decisions, external customers, production systems, purchased software, or records that must be retained.

4. Define the authority and data boundary

Do not upload company, client, employee, personal, licensed, regulated, confidential, or production data into a tool merely because the interface accepts it.

The pilot needs the organization's applicable security, privacy, legal, records, procurement, model-risk, accessibility, and business-owner decisions. The exact path depends on the company and the use.

The NIST AI Risk Management Framework organizes AI risk work around govern, map, measure, and manage. NIST says the functions are continuous rather than a one-time checklist. NIST AI RMF Core

The NIST Generative AI Profile adds cross-sector considerations for generative systems. NIST Generative AI Profile

These are voluntary resources. They help structure a conversation. They do not replace the organization's authority or a rule that applies to the work.

5. State the hypothesis

A pilot should be able to fail.

Write the proposed change, expected mechanism, primary measure, quality threshold, critical-error threshold, and decision rule before the test begins.

A useful hypothesis might say that an approved extraction workflow will reduce median analyst preparation time for a defined document type without reducing field accuracy, increasing critical errors, or moving restricted data outside the approved environment.

That statement is better than "the AI will save time." It names what changes, for whom, under which conditions, and what must not deteriorate.

6. Build the smallest reversible test

Use a prototype to expose assumptions before the organization commits to production.

GOV.UK's prototype guidance says prototypes help teams explore and test before building, and it warns that prototype code should not simply be copied into production. Making prototypes

Reversibility depends on the workflow. A safe test might use synthetic data, previously closed records cleared for the purpose, a parallel run that cannot affect the live decision, or a shadow process where the authorized reviewer remains on the existing path.

The pilot should have an end date, volume limit, participant set, data set, rollback path, support contact, and stop authority.

flowchart LR
    A["Current workflow and baseline"] --> B["Authorized bounded pilot"]
    B --> C["Parallel or reversible test"]
    C --> D["Measure speed, quality, rework, risk, and user experience"]
    D --> E["Stop"]
    D --> F["Iterate"]
    D --> G["Scale through a new decision"]

7. Preserve the human decision

Human review is not a complete control unless the reviewer has time, evidence, competence, and authority to challenge the output.

Define what the system proposes, what the person verifies, which source the person can inspect, what triggers escalation, and who owns the final decision.

The review should become more demanding when the consequence rises. A low-risk internal draft may need a light factual check. A legal filing, coverage decision, valuation, safety conclusion, client recommendation, or public claim can require stronger independent verification and qualified approval.

The American Bar Association's Formal Opinion 512 makes this concrete for legal work. It addresses competence, confidentiality, communication, supervision, candor, verification, and fees. It does not permit a lawyer to transfer professional responsibility to the tool. ABA Formal Opinion 512

That opinion does not govern every occupation. The operating lesson is broader: the accountable professional needs a review design that matches the risk.

8. Measure the completed workflow

Measure from trigger to accepted result, including retries, corrections, escalation, manual review, monitoring, support, and cleanup.

Averages can hide failures. Preserve the distribution and the exceptions.

The United Kingdom's 2026 Test and Learn guidance says very small prototype tests should generate enough insight for the next iteration rather than pretend to provide definitive or generalizable evidence. Test and Learn annex

That is the right ambition for an early internal pilot.

9. Record what failed

The failure log is part of the deliverable.

Record the input condition, expected behavior, observed behavior, consequence, detection method, reviewer action, recovery, and whether the failure changes the pilot.

Do not remove failed cases from the metric because the team later found a better prompt. The prompt change is another version of the workflow.

Failures often reveal the real process. They expose undocumented judgment, inconsistent source data, missing ownership, an exception that dominates the risk, or a downstream dependency the prototype ignored.

10. Decide whether to stop, iterate, or scale

Stopping is a successful decision when the hypothesis fails, the value is too small, the controls are too expensive, the data cannot be used safely, or the workflow is not ready.

Iteration is appropriate when the problem remains valuable and a bounded change can address the evidence. The next test should have its own version, hypothesis, scope, and decision.

Scaling is a new authorization decision. The prototype's result does not authorize production use, more sensitive data, more users, client release, automated decisions, or a new jurisdiction.

Production introduces reliability, access control, logging, monitoring, support, incident response, vendor management, records, accessibility, change management, and ownership requirements that a prototype may not have exercised.

The one-workflow pilot charter

A hypothetical example

Consider a team that receives a recurring set of approved documents and manually prepares a field summary for an authorized analyst.

The pilot does not automate the analyst's decision. It tests whether an approved system can extract a defined field set from synthetic or cleared documents, preserve source references, and prepare an exception queue.

The team establishes a baseline from prior work, predefines field accuracy and critical-error thresholds, runs the new path in parallel, requires the analyst to inspect source evidence, and measures the complete result.

If the workflow is faster but drops a critical clause, the quality threshold fails. If it is accurate but adds more review than it saves, the economic hypothesis fails. If it performs well on the test set, the team has evidence to request a larger pilot, not permission to place it into production.

This is a hypothetical method example. It does not report a Venture Step client or employer result.

Internal entrepreneurship is not the performance of moving fast. It is the discipline of creating credible evidence for a better way to work.

AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.