About

I'm Nick Armstrong.

I lead a team of systems engineers at Cisco, and I've spent two decades building, designing, and defending networks across the Department of Defense.

Eng2Arc is where I share what I've learned at the intersection of deep engineering and business outcomes — for the people willing to take the hard way.

The Thesis

Most people don't want the hard way. Ever.

Engineering is full of paper cuts. Deep technical work is expensive, uncomfortable, and slow. The certifications, the deployments, the 2am troubleshooting calls, the federal acquisition cycles that grind everything to a crawl — 99% of people look at that path and find a way around it.

But the people who go through it — who actually build the deep understanding — discover something the shortcut-takers never find:

Simplicity is on the other side of complexity. Not before it.

The engineer who truly understands a system can explain it in one sentence. The architect who truly understands the business can make a $50M decision feel obvious. The leader who truly understands their people can align a team with a conversation instead of a memo.

That's what Eng2Arc is about. Not complexity for its own sake. Deep understanding as the path to outcomes that are genuinely, powerfully simple.

Each Step an Opportunity, Each Step an Adventure

My first "job" was delivering newspapers. I delivered the Norwalk Times when I was growing up in CT. A couple of bundles of papers, folded, bagged and tossed to avid local news readers.

Since then I've washed and sanded boats at a boat yard, painted houses, served tables at a Chinese restaurant, made copies at an appellate law firm, lived in South Korea as a Mormon missionary, repaired electronics and ran satellite systems in the Marine Corps, pulled and terminated cables in the Pentagon, configured and maintained government networks, and built rack configurations while calculating server power budgets.

It has all led up to my current role at Cisco, and each step has had its ups and downs.

The Marine Corps

I began my IT career as a United States Marine in 2005. I did well enough on the ASVAB to pick any job I wanted, and decided I'd game the system by looking for one with a signing bonus. I settled on one that sounded pretty cool — 2847 Ground Telecommunications Electronics Repair.

We learned basic electrical theory, how to read circuit diagrams, how to solder, fusion splicing for fiber optic cables, and a bunch of other really cool skills. After graduation I went directly to the newly formed Marine Special Operations Command (MARSOC).

Rather than repair hardware, I entered more training to learn data systems, satellite communications, and how to build, operate and maintain a forward operating command post's IT infrastructure. The Marine Corps was a great place to learn the concepts of perseverance and adaptation.

Starting as a Government Contractor

In 2010 I made the decision not to reenlist. I interviewed over the phone at 2AM from the server tent in Afghanistan, pursued an opportunity at an oil and gas exploration company, but just weeks before my last day, I landed a job just outside of Washington DC.

During the interview process I realized I was missing something critical after 5 years of active duty. Paper. I just didn't have the hard credentials needed to easily land a job. The pain of rejection fresh, I threw myself into certification study and within a year had my CompTIA A+ and my CCNA.

My job options opened up and I successfully landed a position as a Jr. Network Engineer. I threw myself into learning and the first major task I was the lead on was a hardware replacement project to replace Cisco 6506 chassis with newer 6506-E chassis.

From Engineer to Architect

That project was where something shifted. I stopped looking at things as tasks and started thinking in terms of a complete project. I built a tracker with inventory information, tracked different steps each chassis would undergo, and created an easy way to share project state across many months.

This approach would be repeated many times over the next 3-4 years. Rather than giving soft responses to management's questions, I could provide concrete evidence of what was happening. I wasn't aware at the time, but I was working as a network engineer and a project manager.

The "whys" grew from small things to larger system-wide questions. With each question more context was created, and a better understanding of the tradeoffs that are made when designing.

The third major skill I needed was reading, understanding and building BoMs — Bill of Material lists. This magical spreadsheet that is an IT nerd's Christmas list of electronic toys. It wasn't until I learned to decode and build them from scratch that I unlocked a whole new world.

I had all the ingredients I needed to become an architect: project management, a systems architecture mindset, and the ability to build a BoM. These were the foundational skills that let me see beyond the command line and expand my reach.

Today

I live just outside Washington DC in Alexandria, VA with my wife and two daughters. When it's not insanely hot and humid outside, we're hiking the parks and trails around Northern Virginia. When it is, we're playing board games or watching sci-fi.

I started Eng2Arc because I kept running into the same pattern — the engineers who go deepest are the ones who eventually make things simplest. That's the thesis. Deep understanding produces simple outcomes. And the people willing to take the hard way deserve a framework for turning that depth into real results.

Get in Touch