Why Working IT at a Small Company Is the Best Job in Tech
At a big company, you have a title. You’re the “Senior Cloud Infrastructure Engineer” and your job is to write Terraform modules. That’s it. Someone else does networking. Someone else does security. Someone else handles the weird printer on the third floor that only works if you power cycle it twice and whisper kind words.
At a small company, you’re all of those people. And honestly? It’s the best thing that ever happened to my career.
Monday Morning: A Case Study
Here’s what a typical Monday looks like when you’re the IT department at a company of 80 people:
8:30 - VPN is down. Users are panicking. You trace it to an expired certificate on the firewall. You renew it, update the monitoring alert that should have caught this, and make a mental note to automate certificate rotation.
9:15 - Someone from finance can’t print. You walk over, ready to explain that turning it off and on again is a real solution, not a joke. Turns out the print spooler crashed. Again. You fix it and quietly start researching cloud printing because you’re tired of this.
10:00 - Meeting about migrating the file server to SharePoint. You’re the one presenting because you’re also the one who’ll be doing it.
11:30 - Azure cost alert fires. Someone left a D-series VM running in the dev subscription over the weekend. You shut it down and write a policy to auto-shutdown dev VMs at 19:00.
13:00 - Security review for a new SaaS tool that HR wants to buy. You’re checking SSO integration, data residency, and whether the vendor’s security page is just a stock photo of a padlock.
14:30 - Back to your actual project: building CI/CD pipelines for the development team.
16:00 - The printer is broken again.
That was one day. You touched networking, security, cloud infrastructure, cost management, vendor evaluation, and a printer with anger management issues. At a big company, that’s six different teams and a ServiceNow ticket that takes three weeks.
Why This Makes You Better
There’s a concept in engineering called T-shaped skills. Deep expertise in one area, broad knowledge across many. Small company IT forces the broad part on you whether you like it or not.
When you’ve configured the firewall rules yourself, you understand why your Terraform deployment fails when it can’t reach the Azure API. When you’ve managed Active Directory, you understand why that service principal authentication is broken. When you’ve set up the monitoring stack, you actually know what’s normal vs what’s a problem.
Enterprise specialists often don’t have this. I’ve seen senior Azure architects who couldn’t troubleshoot a DNS issue because “that’s the networking team’s problem.” At a small company, everything is your problem. And that’s exactly why you learn faster.
The Honest Downside
I’m not going to pretend it’s all fun. There are real downsides:
You’re alone. When something breaks at 2am, there’s no oncall rotation. You’re the rotation. All of it.
You’re the expert by default. Not because you know everything, but because there’s nobody else who knows more. That’s terrifying when you’re standing in front of the CEO explaining why email was down for two hours.
Budget is a joke. “Can we get a SIEM?” “What’s a SIEM?” That conversation. Every year.
No peer review. Your Terraform code is only reviewed by future-you, and future-you will have opinions.
But here’s the thing: every single one of those downsides teaches you something. Being alone teaches you to be thorough. Being the default expert teaches you to learn fast. Budget constraints teach you to be creative. And no peer review teaches you to write code you can understand six months later, because you will be debugging it at the worst possible time.
The Printer Is a Metaphor
Every small IT department has The Printer. The one device that breaks constantly, that everyone complains about, that you’ve fixed so many times you could do it blindfolded.
The Printer is a metaphor for everything in small company IT. It’s not glamorous. It won’t look good on your LinkedIn. Nobody at a tech conference wants to hear about your printer. But fixing The Printer teaches you patience, user communication, vendor management, and the ability to stay calm while someone from accounting watches over your shoulder saying “it was working yesterday.”
Those are the same skills you need when a production deployment goes sideways and the CEO is in the Slack channel asking what happened.
Enterprise People Don’t Get It
I’ve talked to engineers at large companies who look at my work history and ask “but what’s your specialization?” As if doing one thing is inherently better than doing many things.
My specialization is solving problems. Whatever the problem is. Firewall? Sure. Terraform module? Got it. Azure landing zone? On it. Printer? Unfortunately, also on it.
When you’ve been the person responsible for the entire stack, you develop something that no certification can give you: intuition for how systems connect. You know that the weird latency issue is probably related to the DNS change last week because you made both changes. You know that the deployment failure is because of the firewall rule you updated yesterday because you updated it.
Context. That’s what you get from wearing all the hats. And context is the one thing AI can’t replace. It is also what keeps you from walking into a new system and immediately misreading it, which I wrote about in more detail in Improvement Is a Skill, Not an Opinion.
Who Should Do This
If you’re early in your career and you’re choosing between a junior role at a Fortune 500 where you’ll manage one Kubernetes namespace, and a role at a 50-person company where you’ll manage everything - pick the small company. Stay there for two or three years. Touch everything. Break things. Fix them.
Then, if you want to specialize, you’ll specialize with context. You’ll be the Terraform engineer who actually understands what happens when someone presses “print.” And trust me, that person is way more valuable than the one who only knows Terraform.
Unless the printer breaks again. Then nobody is valuable. We’re all just suffering together.