From Army Officer to Software Founder

I joined the Florida Army National Guard in 2011. Basic training was at Fort Sill, Officer Candidate School at the Florida Regional Training Institute, and after that came the Field Artillery jobs: fire direction officer, platoon leader, executive officer, and two battery commands. One was an M777A2 howitzer battery of about 85 Soldiers. The other was the headquarters battery of a HIMARS battalion, with more than 110.

The software career started earlier, in 2008, and never stopped for the Guard. I went through the Captain's Career Course at Fort Sill between 2017 and 2019 while working as principal engineer on a payroll and HR platform at CertiPay, and I started Red Leg Dev in the middle of it. Since then I've founded or co-founded nine software products.

People ask what carries over from one to the other. They usually expect something about discipline. My list is shorter and more specific than that, and a couple of items on it come from jobs most people outside the Army have never heard of.

Give the team most of the time

The Army calls its leadership model mission command. You hand down the intent and the constraints, and the people closest to the problem work out how. A leader who keeps every decision becomes the bottleneck for all of them.

What I find more useful than the philosophy is the arithmetic attached to it. Under the one-third, two-thirds rule, a leader spends no more than a third of the available planning time on their own plan and leaves the other two thirds for subordinates to plan their part. I hold officer candidates to it now, and I've broken it in software more often than I'd like. Every time, it was because I wanted the answer to be mine.

In engineering the violation looks ordinary. A lead spends two weeks on a design doc, the deadline doesn't move, and the team gets three days to build what took two weeks to describe. The doc is usually fine. The team just never had time to find out where it was wrong.

Check the data before it leaves

A fire direction center takes a call for fire and turns it into data the guns can shoot. Before that data goes out, it gets checked, including against the safety limits for where rounds are allowed to land. As the fire direction officer, that check was my job. Nobody treated it as bureaucracy, because a wrong number has a physical address.

Software mistakes are rarely that serious, which is exactly why teams skip the check. I want review and deploy gates on client work for this reason. The person who wrote the change is the worst-placed person to catch what they got wrong in it.

Hurricanes, inaugurations, and outages

I led Guard coordination through five major hurricanes and two presidential inaugurations. State active duty is messy. The operating picture changes by the hour and the chain of command is stretched across people who don't normally work together. The leaders who do well in that environment give their Soldiers clear orders and keep higher informed without flooding them. The second habit is rarer than the first.

In my experience, production incidents go wrong on that point more than any other. Someone posts every new theory into the incident channel, the people who need a decision can't find the current state, and the engineer fixing the problem spends half the hour answering questions. My preference is a status update on a fixed cadence: what we know, what changed since the last one, and when the next one comes. Everything else stays in a side thread.

The two careers crossed here more than once. In 2017 I gave a talk at Tampa Code Camp on resiliency patterns for managing failure, and in December 2020 I presented at Avengercon V on rapid application development for emergency response, mostly about using low-code tools to get software into the hands of people running emergency operations quickly.

Teaching it now

These days my Guard job is senior platoon trainer at the OCS detachment at Camp Blanding, the same school I went through. I coach officer candidates through their leadership positions, review the orders they write, and write their counselings.

Two habits from that work have made it into how I run software projects. The first is about feedback. When I review a candidate's operation order I send back a few fixes that matter. A list of twenty comments gets the easy nineteen fixed and the important one lost, and code review works the same way.

The second is that the Army makes you write expectations down at the start. Before a candidate takes a leadership position, they get an initial counseling that says what the position requires and what success looks like, on paper, signed by both of us. Client work gets a version of that from me: what “done” means, written down before anyone writes code.

Priority of fires

In the artillery, there are never enough guns for every unit that wants support, so the commander assigns priority of fires. One unit gets first call. Everyone else waits, and everyone knows the order ahead of time.

Running a startup has the same shortage with different nouns: not enough hours or engineers for everything the product could do this month. The founders I see struggle most have usually avoided ranking anything, so every request competes with every other one and the loudest wins. Pick the one thing that gets first call this week and tell people what waits.

Not all nine of my products are still running, and I'm no longer involved in some of them. The one where the two careers meet most directly is WriteMyNCOER, which I launched in March 2023 to generate Army evaluation narratives with an LLM. Writing NCOER bullets is a chore every rater in the Army knows, and it was an early, obvious job for a language model.

On “veteran-owned”

Red Leg Dev is veteran-owned, and the name comes from the Field Artillery. I keep both low-key. Neither gets you a discount or a guarantee, and if someone else is better suited to your project you should hire them. What fifteen years in the Guard gave me is a habit of showing up prepared and finishing what I started.