The best operations look boring from the outside. I spent 21 years in the Navy learning that. Now I build software with the same principle: if your tool creates drama, you built the wrong tool.
But I didn’t learn this from software. I learned it from operations. The kind where if something breaks, people don’t file a support ticket — they miss a mission. The kind where the person executing the plan is the most important person in the room, even though they’re usually the lowest-ranking person in the room.
The kind where complexity is the enemy and simplicity is the discipline.
I didn’t know I was learning how to build software. I was just learning how to build systems that don’t fail the people who use them.
Drama Is a Symptom, Not a Feature
When everything is working — when the logistics are moving, when the team knows their role, when the communication is clear and the timeline is tight — nothing dramatic happens. The mission executes. People do their jobs. Things get done on time. Nobody scrambles. Nobody panics. Nobody stays late fixing something that should have been handled hours ago.
That’s not luck. That’s design.
The drama comes from bad systems. The 2 AM crisis call happens because someone didn’t have the information they needed at 2 PM. The missed deadline happens because the tracking system was too complicated for the person responsible to use under pressure. The miscommunication happens because the process assumed everyone was paying attention to the same channel at the same time.
Good operations eliminate drama. They don’t create it.
I think about this every time I design a feature in DocJacket. If the TC is scrambling at 9 PM to figure out which deadlines they missed, the software failed. If the agent has to check four different screens to understand where a deal stands, the software failed. The goal isn’t a powerful tool. The goal is a boring Tuesday — where everything is on track, nothing is on fire, and you close your laptop at a reasonable hour.
Build for the Person Executing, Not the Person Reviewing
In the military, there’s always a tension between headquarters and the field. Headquarters wants reports. The field wants to execute. Headquarters wants dashboards. The field wants clear orders. Headquarters wants visibility. The field wants to be left alone to do the job.
This tension exists in every organization. And the system you build always reveals which side you’re on.
When you build for headquarters, you get reporting tools. Dashboards. Status updates that someone on the ground has to fill out so someone at a desk can review it. The work of reporting about the mission becomes a job in itself — and it gets done instead of the actual mission.
When you build for the field, you get tools that reduce the operator’s workload. Clear task lists. Automated status updates that happen as the work happens, not as a separate step. Information that flows to the person who needs it without anyone having to compile a report.
The best commanding officers I served under understood this. They didn’t ask for more reports. They built systems where the information they needed was a byproduct of the work being done — not an additional burden on the people doing it.
That’s exactly how I think about DocJacket. When a TC approves a timeline that the AI extracted from a contract, the “report” is already done. If there’s a managing broker who needs to see status — fine, they can see it. If you’re an Independent operator with no broker above you — fine, the audit trail still exists for your own records and for compliance. Either way, the TC didn’t have to do anything extra. The reporting was a byproduct of the work, not a separate task.
Software built for compliance makes the operator do work so the reviewer can see a report. Software built for operators makes the work produce the report automatically. The difference is who carries the burden.
Simplicity Is a Discipline
Most people think simplicity means fewer features. It doesn’t. Simplicity means fewer decisions for the person under pressure.
In Navy operations, the worst thing you can hand someone in a high-tempo situation is a tool with options. “You could do this or this or this — it depends on the situation.” That’s not a tool. That’s a puzzle. Under pressure, people don’t want choices. They want clarity.
The best operational tools I ever used were the ones that made the next step obvious. Not a menu of possibilities. Not a screen full of data. Just: here’s what’s happening, here’s what you need to do, here’s the button that does it.
This shaped everything about how I build DocJacket. When a TC uploads a contract, the AI extracts the data and populates the timeline. The TC doesn’t choose which fields to map. They don’t configure the extraction. They don’t decide how to organize the dates. The system does it, and the TC reviews the result.
That’s not because TCs can’t handle complexity. They handle more complexity before lunch than most people handle all week. It’s because their complexity should be the deal — the negotiation, the client, the problem-solving. Not the software. The software should be the simplest thing in their day.
Simplicity isn’t dumbing things down. It’s doing the hard design work so the user doesn’t have to do the hard thinking work. Making something simple to use is the hardest thing to build. But it’s the only thing worth building for someone who’s managing 25 active files and doesn’t have time to learn your interface.
Redundancy Isn’t Waste
The military plans for failure. Not because things always fail, but because when they do, the consequences are unacceptable. So you build redundancy into everything. Backup communication channels. Alternate supply routes. Secondary plans for every primary plan.
Most software ignores this. Something goes wrong and you get a spinning wheel, an error message, or silence. The user is left wondering what happened and what to do next.
In real estate, failure has real consequences too. A missed deadline isn’t a bug — it’s a blown contingency. A lost document isn’t a glitch — it’s a delayed closing. An email that didn’t send isn’t an edge case — it’s a relationship damaged.
This is why DocJacket sends deadline reminders before things are due, not just after they’re missed. It’s why documents are stored with the transaction, not in a folder hierarchy that one person understands. It’s why the AI flags things that look unusual — a short contingency period, a weekend closing date — before they become problems.
You don’t build for when everything goes right. You build for when someone is tired, distracted, managing too many things at once, and about to miss something important. Because that’s not the edge case. In real estate transaction management, that’s Tuesday.
Train for the Worst Day
In the Navy, we didn’t train for the easy days. We trained for the worst ones. The scenario where everything goes sideways at once. Multiple problems, limited time, incomplete information.
The goal wasn’t to prevent those days — you can’t. The goal was to make sure that when they came, the system was strong enough that the person executing could still perform. That the process was clear enough to follow under stress. That the tools didn’t add confusion when confusion was already everywhere.
I think about this when I imagine the TC who just got three new contracts in one morning, has two contingency deadlines this afternoon, a client calling about an inspection report, and an agent who hasn’t returned an email in three days. That’s their worst day. That’s the day the software has to earn its keep.
If the software makes that day even slightly worse — one extra click, one confusing screen, one piece of information that’s hard to find — it’s failed. If the software makes that day manageable — surfaces what’s urgent, handles the setup, drafts the emails — it’s done its job.
I don’t design for the TC who has five active files and time to spare. I design for the one who has 25 files and needs the software to carry part of the weight. Because that’s the person who needs it most, and that’s the person every competitor forgets about when they’re building for demos instead of Tuesdays.
Operations Is a Mindset
I don’t think of operations as a job. I think of it as a way of seeing problems.
Every problem is a system. Every system has a bottleneck. Every bottleneck has a cause. And the cause is almost never “the person wasn’t working hard enough.” It’s almost always “the system made the right thing harder than it should be.”
Real estate transaction coordination is an operations problem. The industry treats it like a compliance problem or a document management problem or a CRM problem. It’s none of those. It’s an operations problem — how do you move 25 deals through a complex, multi-party process with hard deadlines and zero margin for error?
That’s a question I spent 21 years learning how to answer. Not in real estate. In the Navy. But the principles are the same.
Build for the person executing the mission. Make the system simple enough to use under pressure. Design for the worst day, not the best one. Let the reports be a byproduct of the work, not a separate burden. And make the best outcome the boring one — where everything just works.
That’s exactly what DocJacket is.
DocJacket is AI transaction coordinator software for Independent TCs, Brokers & Agents. Built by an operator, for operators. No demo, no IT ticket. Upload a contract and see what happens. Start here.
