The first team anyone trusted me with was eight missionaries on the east coast of Madagascar.
I was the zone leader in Toamasina in 2006 and 2007, nineteen and twenty years old. Most of our mission’s roughly sixty missionaries were inland in Antananarivo, near the mission office. We were the ones on the coast, at the end of one bad road and a small airport, in the part of the country where category 5 cyclones make landfall.
When a cyclone came through, the sequence was predictable. Flooding closed the roads. The power went out, and with it every way of reaching the mission office. No one was coming, and no one could even ask how we were doing. The safety of the missionaries in my zone was my responsibility, and so, in practice, was helping the local church members and our neighbors get through it.
One storm I remember in particular. We saw it coming, so we filled every container in the apartment that could hold water, and then the power went out. It should have been a frightening night. Instead we cooked everything in the dying refrigerator, ate well by candlelight, and went out the next morning to help neighbors bail out their flooded homes. Power came back in a day or two, the phone rang, and I reported to the mission president: everyone accounted for, here is what happened, here is what we did.
At the end of my mission, the president told me how much he had trusted my judgment, and that he had stopped worrying about Toamasina. I have thought about that sentence for twenty years, because it describes the job I have been doing ever since: be the person responsible for a small team, far from headquarters, who can be trusted to handle whatever arrives.
Small teams are a choice, not a constraint
Every team I have led has been small. Eight missionaries in a cyclone. A handful of junior engineers in 2015, when I built a cloud network automation product and then trained that team to run it day to day. The engineering, development, and maintenance teams I built as CTO of Rimstorm, which operated GovCon Enclave from concept through its 2026 acquisition.
For a long time I treated that as a gap in my resume. Other technical leaders could say “I managed an org of 200,” and I could not. I have come to believe the opposite: small teams are the discipline, not the deficiency.
A small team cannot hide behind process. Every person has to own their lane, understand why the work matters, and make good calls when the runbook runs out, because there is no one else to escalate to. That is the Toamasina condition: the road is closed, the phone is dead, and the situation does not care that you would prefer to check with someone first. Building a team that thrives in that condition is a different skill from administering a large one, and for a startup it is the skill that matters.
The economics agree. At Rimstorm we drove enclave deployment from two weeks of manual work to two hours of automation, and a deliberately small team scaled the platform past fifty production environments supporting hundreds of users. Customers grew; headcount did not grow in lockstep. Every dollar of that leverage came from the same trade: invest in automation and in people deep enough to wield it, instead of adding hands to do the work manually.
What I actually do
In 2021 I took Academy Leadership’s Leadership Excellence Course, which forced me to write down what I had been doing by instinct since Madagascar. The philosophy has not changed much since, because it keeps working.
The course also put words to a tension I had felt for years. My Energize2Lead profile reads Red/Blue in preferred style: the individualistic builder who wants to set an ambitious project and go achieve it, with urgency and an independent course of action. But my expectations and instinctive needs both read Yellow/Blue: involve people, encourage questions, keep an open door, understand and be understood. (If the color language is new to you, Academy Leadership publishes a sample profile showing how the three dimensions and four color traits work.) For a long time those felt like two different people. They are actually the job description of a founding technical leader: build like a pioneer, lead through involvement. The builder side ships the platform; the people side builds the team that outlives my attention.
What my team can expect from me. An open door, about anything, with real time set aside if the topic needs it. I champion my people: I look for chances for them to grow and I back their actions in public. I share news that affects the team as soon as I have it. And I share credit for our wins while owning our failures myself, because team morale is my responsibility, not the team’s.
What I expect from the team. Ownership: make the task yours, and understand how it serves the mission this week, in six months, and in two years. No surprises: when something threatens the schedule or the goal, I want to know immediately, while it is still cheap to fix. Honesty over comfort: tell me the facts, not what you think I want to hear. Mentoring as a default: everyone has something to teach, and a team that trains itself compounds.
What I will not tolerate. Coasting, and internal competition. Undermining a teammate, scapegoating, and gossip are the fastest ways off my team, because a small team that turns on itself has no slack to absorb the damage. We compete with competitors, not with each other.
How decisions get made. Knowledge and judgment are the ultimate source of authority, not hierarchy. I want every viewpoint heard before the call, and I explain the why of every decision afterward so the team stays aligned even when someone disagrees with the outcome.
And underneath all of it: families come first. You will have your family far longer than any job. A team that knows this is true, and not a poster, will give you their best hours without being asked for their worst ones.
Trust is the deliverable
None of this is exotic. Written down, it looks like common sense, and most leadership philosophies do. The difference is made in the moments when the philosophy is expensive: owning a failure in front of a customer, spending CTO hours training a junior engineer when a senior hire would be faster, saying no to bespoke revenue to keep one product whole, telling the team hard news on the day you learn it.
What you get back, if you pay those costs consistently, is the thing I got from a phone call in Toamasina when the power came back: a leader above you who has stopped worrying about your corner of the map, and a team below you that handles cyclones by filling the water containers, cooking a good dinner, and showing up for the neighbors in the morning.
That is what I build. Small teams you can stop worrying about.