Five Years Later at Dojo Networks: Perspective from the Inside

Five years ago this month, I made a phone call that changed the direction of my career.

I wasn't casually job hunting. The company I worked for had been acquired, and the contract I received from the acquiring company felt like a step backward. I accepted it reluctantly because I needed somewhere to land, but I was already looking for something better.

Then Dojo Networks reached out.

I actually started at Dojo two weeks before I was supposed to start with the acquiring company. After two days here, I called them and told them I was going in a different direction. Two days. No hesitation.

Five years later, I think I finally understand why I was so sure. And more than anything, I want to say thank you to the people who made that decision worth it.

Day One

What struck me in those first 48 hours wasn't a particular vendor, protocol, or piece of hardware. It was the architecture. You could tell almost immediately that the network had been designed by people who had operated networks when things went wrong.

There is a difference between a network that looks good on a Lucidchart diagram and one that has clearly survived Friday-night outages, bad optics, fiber cuts, failed power supplies, and maintenance windows that did not go according to plan. Dojo's network was the second kind. The redundancy lived in the transport, where failure actually matters: multiple paths, BGP convergence behavior, failure domains, and the relationship between each property and the wider backbone, all thought through by people who had been burned before.

The access side was just as deliberate. Making thousands of residential networks behave like individual homes on shared infrastructure is one of the hardest problems in multifamily, and Dojo had already solved a lot of it: per-resident segmentation with dynamic VLANs and DPSK, roaming across access points and floors, and an RF layer that continuously adjusts itself instead of waiting for someone to open a ticket about slow bedroom WiFi. That was not common in MDU five years ago.

The thing I did not expect was the book. Everyone who joins Dojo reads Delivering Knock Your Socks Off Service, network engineers included. It is not a support-department book here. It is closer to the operating philosophy of the whole company. The person answering the phone, the technician replacing a switch, and the engineer designing failover are all supposed to be thinking about the same resident. Residents are never expected to understand VLANs, RF, or whether the problem is upstream of the property. They need the internet to work, and when they need a person, they get one quickly.

I recognized what I was looking at. This wasn't a network built to pass an acceptance test. It was a network built to be operated, by a company that had decided what it was operating it for. That was enough for me to make the phone call.

Birmingham, and Designing Around the Provider

One project from those early years still sticks with me. We had four properties in Birmingham, Alabama, and the upstream circuit provider there was having enough problems that eventually our boss got tired of hearing about it. It would have been easy to open another ticket with the carrier and tell residents to hang on. Instead, his direction to engineering was basically: make these four properties able to keep each other online. Then he did the harder part, which was giving us the time and the budget to build something ambitious. Easy sentence. Not an easy project.

We designed and built a full-mesh, 10G-capable wireless backbone between the four sites, so a property no longer had to live or die with its primary circuit. That meant working out the point-to-point radio paths, the inter-site transport VLANs, the routing, and what should happen when a circuit disappeared without creating a new problem somewhere else in the topology. I remember how hard it felt at the time: a lot of diagrams, a lot of testing, and more than one evening where the design made considerably more sense on paper than it did at the other end of a CLI. I learned an enormous amount building it.

Years later, my favorite part is that the backbone is still doing what we designed it to do. A primary path fails, traffic moves to the alternate, and nobody has to rebuild the network in the middle of an outage. Watching a failover happen today is almost boring, which is exactly what we wanted.

Birmingham is one example, and there are others like it across the footprint. Nobody approved a wireless mesh because mesh is cool. They approved it because residents shouldn't lose internet just because a carrier can't get its act together, and because the instinct here is to remove the underlying problem rather than live with chronic failure. But four properties is a project. Keeping every property that solid, all the time, is a different job entirely. And that is where most of my five years went.

Then the Network Got Much Bigger

When I joined, Dojo was a State College, Pennsylvania company with national ambition. Today we serve communities in more than 32 states, and we're still expanding. In both 2025 and 2026, Dojo Networks was named to the Inc. 5000 list of America's fastest-growing private companies.

Watching that growth from the inside is interesting because you see the part nobody puts in the announcement. Every new property means more switches, more circuits, more VLANs, more configurations to keep consistent, and more things somebody can accidentally set up differently from the property next door. At a small scale, you can compensate for inconsistency with good engineers. At a large scale, inconsistency becomes the outage.

Our local loop now runs on 100G links with multiple transport paths underneath it, but the bandwidth was never the hard part. The hard part was everything around it.

The Operating System Around the Network

At some point, we stopped thinking of the network as thousands of boxes that engineers configure one at a time and started building the systems that configure them.

It starts with Elemento. And Elemento started with a problem every operator eventually runs into: too many systems. Provisioning in one place. Billing in another. Property information somewhere else. Subscribers and support tools somewhere else again. Then a collection of scripts, spreadsheets, and patient humans trying to keep all of it in sync.

Rather than accept that this is just how ISPs work, Dojo built what it needed.

Elemento is the source of truth for the business. The property exists once. The subscriber exists once. The service exists once. Provisioning, billing across bulk and retail models, PMS integration, and support context all hang off that one model instead of depending on somebody copying information between screens.

Nautobot is integrated with it and holds the network model that follows from it: devices and their roles, interfaces, VLANs, prefixes, IP addresses, platforms, and the configuration each device is supposed to be running. Automation connects the two.

Jobs and templates turn intent into vendor-specific configuration, push it, back it up, and then compliance checks whether reality still matches what we intended. Drift gets detected instead of discovered during an outage. A switch shouldn't quietly wander from the standard because somebody changed something six months ago and forgot. Now it can't wander for long.

The example I use when people ask what this looks like in practice is unit-to-port mapping. A field tech tells us that, say, Unit 625 lands on port 1/1/31. The system already knows which VLAN belongs to Unit 625. A Job takes the mapping for the whole property, validates it, renders the correct syntax for whatever vendor is in that closet, configures the VLAN membership, labels the interface, and moves on to the next port. Nobody types it. Nobody puts Unit 652 on the port meant for 625.

A new property used to mean copying an old config, changing a few VLAN IDs, hoping nothing was missed, and sending it to the field. Now property information becomes intent. Intent becomes configuration. The same input produces the same result every time.

Some of those Jobs run on a schedule without anyone kicking them off: backups, compliance evaluation, synchronization between the two systems, validation. That is the difference between a network that is administered and one that is operated as a system.

A lot of my own work over these five years has been about exactly this: taking things that lived in an engineer's head, a spreadsheet, an old config file, or tribal knowledge and turning them into systems that can be repeated safely. Getting the whole network into Nautobot and integrating it with Elemento. Building the Jobs, templating, and compliance on top of that. Monitoring. Cloud infrastructure. Provisioning workflows. And increasingly, the plumbing between them so that operational intent flows all the way down to the switchport.

We do it because nobody should be typing the same forty lines of config into hundreds of switches. And because a typo at 2 PM is annoying, while a typo at 3 AM during a maintenance window is a very different experience. I have absolutely been the engineer staring at a terminal at 3 AM wondering why something that worked in the lab had developed a personality in production.

None of this shows up on an invoice the day you build it. And none of it happens without leadership willing to fund engineering time and software that pay off quietly, later, in outages that never occur. That is the same instinct that approved Birmingham, applied to every property at once.

And there is a real difference between software built for an ISP and software built inside one. The people building Elemento know what happens when a provisioning workflow fails halfway through, and why "device offline" is not enough information for anyone trying to help a resident. They know because they operate the environment. It is what happens when the people writing the software are close enough to the network to have carried the pager.

None of this was about eliminating engineers. It was about eliminating the work engineers shouldn't still be doing by hand, so they have more time to actually engineer. Birmingham keeps four properties online. This keeps every property consistent, quietly, every single day. Some of the engineering work I'm proudest of at Dojo is the stuff nobody notices when it works.

The Part Nobody Can Automate

For all of that, the most important part of Dojo still isn't automated. It's the people, and the fact that all of them are pointed at the same resident.

I have seen our CEO troubleshooting a single resident's ticket at 9 PM on a Saturday. Not an outage. Not a property. One resident. More than once.

If the CEO does that, you can guess what the CTO does, and the support manager, the NOC technicians, Tier 2, the engineers, and the people on the phones. Everyone here attacks tickets, which is one reason I'd bet our ticket count is among the lowest in this industry.

The other reason is the network from earlier. Resilient systems don't create many tickets to begin with, and the ones that do get created have the whole company coming at them.

Support is not a call center reading a script. When they pick up, and they pick up fast, they can see the property, the switch, the access point, and the resident's service in one view, so the conversation starts with a diagnosis instead of a request to describe blinking lights.

Field technicians treat a dead switch during move-in weekend as their problem, not the resident's. The software team sits close enough to support to hear what breaks. Engineers spend their days on automation for the same reason: a resident three states away should get the same experience as one down the street from the office. Different jobs. Same philosophy.

My favorite version of the engineering culture is two engineers arguing about a design for an hour, testing both ideas, discovering both were partly wrong, and ending up with something better than either. I've had plenty of those arguments here.

People at Dojo care about being right, but they care more about the network being right. If someone brings a better idea, we use it. If something breaks twice, somebody starts asking why the system allowed it to happen twice. And when a lesson is learned the hard way at one property, the expectation is that every other property benefits from it.

That's how infrastructure gets better. Not because failures stop happening. They don't. Networks will always find creative new ways to humble you. But because you learn from each one.

One more thing, and it has nothing to do with the network. You can learn a lot about a company from its calendar.

At Dojo, MLK Day is a day off. The scheduled Jobs still run that Monday. The people get the day.

And on Juneteenth, a message was posted to the company Slack channel. Not a graphic. An actual note asking people to take some time and learn what the day represents.

Both of those meant a lot to me, and they told me something about the people leading this company that has nothing to do with bandwidth. The book says everyone here is expected to understand how we treat residents. That message said something similar about the world outside our tickets: keep learning, even when it isn't your job.

What Five Years Changed for Me

I'm a much better engineer than I was five years ago, and my job has changed with me. I still love getting into routing tables, packet captures, configs, fiber paths, and wireless behavior. All the things that made me fall in love with networking in the first place.

But the questions have gotten bigger. How do we make this repeatable and observable? How do we make sure the next engineer can understand it? How do we stop a failure across every property instead of fixing it at one? How does a relatively small team run infrastructure at national scale without living permanently inside an incident channel?

Five years ago, I solved networks. Now I mostly build systems that solve networks.

Those are harder problems, and much more interesting. Dojo gave me the room to work on them, and the people around me forced me to get better at solving them. Not because anyone told me I needed to improve, but because the bar here is high and the people around me clear it every day.

That is probably the best definition of a good engineering culture I've found: You become better almost without realizing it's happening at all.

Five Years In

I've been doing this long enough to know that environments like this are rare. A lot of companies talk about innovation. The difference here is that engineers actually get to build it, deploy it, break it occasionally, learn from it, and deploy the better version.

Five years ago, I spent two days at Dojo Networks and decided to walk away from another job. At the time, it was mostly instinct.

Now I have a better explanation.

I saw a company that took engineering seriously. I saw leaders who would rather fund the fix than manage the complaint, and who will still work a single ticket on a Saturday night. And I saw a place where the person answering the phone and the person designing the backbone were working from the same book.

I knew I would learn here.

I was right.

Thank you to everyone who has been part of these five years: the leadership team for telling engineering to fix the problem instead of managing the complaint, and then paying for it; my fellow engineers for the arguments, the late nights, and the constant push to make things better; our software teams for turning operational problems into tools; our support teams for being the reason the phone gets answered by someone who already knows what's wrong; our field teams for doing the work no dashboard can do from behind a keyboard; and our partners and residents for trusting all of us with something that has become fundamental to everyday life.

And I have to give a special shoutout to our CTO, probably one of the nicest humans you will ever meet. He is the one who hired me five years ago and gave me the opportunity to be part of all of this. Michael Caldwell, thank you for taking a chance on me. Five years later, I’m still incredibly grateful you did.

Walking away from that other offer after two days remains one of the best decisions I've made in my career.

Here's to the next five. There is still a lot left to build.