Writing
When "Move Fast" Meets "Move Safely" - Reconciling the Startup Builder Mindset with Enterprise Reality
The startup instinct says move until reality stops you. I've worked at startups and at very large companies, and the difference isn't that reality stops you sooner at the big ones — it's that reality arrives earlier and in writing: privacy review, security review, legal exposure, customer trust, and production systems that cannot be casually broken. AI makes the tension sharper than it's ever been, because the prototypes have never been faster to build and the blast radius has never been easier to underestimate.
Enterprises aren't slow because they lack courage
This took me longer to internalize than I'd like to admit. The startup framing treats process as cowardice — accumulated scar tissue from people too timid to ship. Sometimes it is. But mostly, large companies are slow because they carry accumulated downside: customers who trust them, regulators who watch them, systems whose failure costs real people real money. The reviewer across the table isn't an obstacle to your cleverness. They're the owner of a specific piece of downside, and they will still own it after your demo is over and you've moved on to the next project.
Once you see it that way, the move stops being "find a way around the gates" and becomes "give the gate owner something they can actually say yes to."
Translate speed instead of abandoning it
The useful skill is translation. For any risky AI workflow, build the control package before you ask for permission: name the blast radius, list the actions the system is allowed to take, define the evidence an operator sees before approving, write down the rollback path, and instrument the outcome. That hands the risk owner a concrete object to evaluate instead of a vague request to trust the team. In my experience the conversation changes completely — you've done their first hour of thinking for them, and it shows that you understand their job rather than merely tolerating it.
It also helps to map the full sequence of gates at the start instead of discovering them one meeting at a time. The second mode feels like momentum because you're always busy. It's actually the slowest possible path, just with better morale in the early weeks.
Before asking anyone to approve an AI workflow, I want crisp answers to five questions: What can the system do on day one? What is explicitly out of scope? What evidence does the operator see before approving an action? What metric proves this is safer, faster, or cheaper? And what switch turns it off if the metric moves the wrong way? If I can't answer these, the proposal isn't bold — it's just unfinished.
The two instincts need each other
The startup instinct contributes something real: it forces a narrow, concrete first version instead of a strategy document. The enterprise instinct contributes the question startups defer: what happens when this works and has to scale? The builder's job is to hold both — ship the small controlled path, designed so it can grow into a durable platform rather than remaining a one-off demo with a kill switch.
The mental model I'd name here is measured aggression: move as fast as you can inside a control system strong enough that the organization can keep saying yes. That control system — gateways, runtimes, traces, the whole stack — is what the AI-for-Work series is about. This essay is the disposition you need to build it.