Why I Don't Chase Developer Jobs (And Neither Should Most CS Grads)

Every Computer Science graduate I've ever met walked across the stage with the same assumption: the point of the degree was to become a developer. Full-stack engineer. Backend. Mobile. Maybe data.

I graduated with a CS degree from the University of Eldoret in 2015 and made a quiet decision a few months later: I was not going to chase a developer job. I was going to work in IT support, operations, automation, and customer experience instead.

Eleven years on, that's still the best career decision I've made. This is why — and why I think most CS graduates would be better off making the same call.

The Math Nobody Shows You

At my graduation, over a hundred of us walked out with CS degrees. Most of us wanted the same jobs. The local developer market could comfortably absorb maybe a fifth of that class — the ones with GitHub portfolios, internships, and the kind of family networks that put CVs in front of CTOs.

The other four-fifths of us were going to compete for the same narrow slice of openings. Some would squeeze in. Most would end up freelancing for small clients, taking jobs unrelated to tech, or spending a year unemployed trying to crack the interview loop.

Meanwhile, just next to that narrow developer slice, there was a much wider market most of us had been trained to look past:

• IT support and helpdesk roles
• System administration and infrastructure
• Technical customer success and SaaS support
• Operations and workflow roles
• Automation engineering
• Technical project management
• Data analysis and reporting
• CRM and revenue ops

These jobs pay well. They hire faster. They don't require a leetcode gauntlet to clear the interview. And — this matters — there are dramatically more of them than there are developer roles.

The Assumption That Holds Most People Back

The assumption is that these roles are "less technical" or "beneath" a CS degree. That a support engineer is a failed developer. That ops is where you go when you can't code.

It's wrong, and it costs people years.

The IT and ops work I've done in the last decade has been as technical as any dev job I'd have taken in Nairobi. I've architected Active Directory for a 30-branch NGO. Designed offline-first data pipelines. Built automated workflows in n8n integrating six systems. Deployed AI-drafted response tooling using Claude and OpenAI APIs. Administered Microsoft 365 tenants. Managed cybersecurity postures under real threat models. None of this would have been on a developer's to-do list.

"Technical" and "writes code all day" are not synonyms. The people who conflate them tend to underestimate the wider industry for years before they come around.

Why These Paths Compound Faster for Most People

Three reasons, roughly in order:

1. The talent gap is wider. Every mid-sized company needs IT support, systems admin, and ops. Not every company needs another junior developer. You'll get interviewed, hired, and trusted with scope faster in the wider market than in the narrow one.
2. The skills you build are cross-industry. A backend developer at an insurance company and a backend developer at a gaming studio solve different problems with different stacks. An IT ops engineer at both companies solves the same problems with the same stack. Your skills travel cleanly.
3. Exposure to the business is baked in. Developers typically see one part of the product. Ops and support roles see how the whole organisation actually works — finance, sales, customers, infrastructure. That exposure turns into leverage when you're ready to move into leadership, consulting, or founding something.

The Automation-Engineer Wave Nobody Is Paying Attention To

Since 2022, a new category of role has been quietly taking shape: automation engineer or AI workflow designer. The job is to connect systems with tools like n8n, Zapier, and the OpenAI/Anthropic APIs, and to build AI-assisted internal tooling that replaces manual work.

A few things make this category unusually interesting right now:

• Almost no one in the market calls themselves an "automation engineer" yet. The supply of specialists is tiny.
• Almost every mid-sized company has identified manual work that needs automating. Demand is already there.
• The entry bar is low. You don't need a CS degree, a bootcamp, or a five-year developer track record. You need to understand business workflows and know a handful of tools deeply.
• The salary bands are competitive with mid-level development roles — and the work is generally less grindy.

I fell into this category by accident. I'd been doing IT ops, started automating things internally at xFusion with n8n, and realised I enjoyed it more than the rest of the job. Five years later, it's half my day and a significant share of my pay. There was no textbook for this path when I started. There barely is one now.

Who This Advice Is Not For

To be clear — this is not a "don't become a developer" post. Development is a great career for a specific kind of person:

• You actually love writing code for 6+ hours a day
• You're excited by language design, performance, systems thinking
• You have the appetite to grind the interview loop and the personal projects that precede it
• You can tolerate narrow scope for years in exchange for deep expertise

If that sounds like you, chase dev jobs. Go hard. The top of that ladder is genuinely worth climbing.

But if you're nodding along because you think you're supposed to — or because everyone around you in the CS programme was — pause. The signal that you should be a developer is "I love this." It isn't "I completed the degree."

How to Start If You're Early

If you're a CS student or a recent graduate and this is landing, here's what I'd do in your first twelve months out of school:

1. Get three globally legible certifications. ITIL Foundation, CompTIA A+, Google IT Support. Combined cost under $500. They'll open interview doors a fresh degree doesn't.
2. Pick a tool stack and go deep. One CRM (HubSpot or Pipedrive), one automation platform (n8n or Zapier), one support tool (Help Scout, Zendesk, or Intercom), one cloud admin domain (M365 or Google Workspace). Depth beats breadth at entry level.
3. Take the first IT/ops/support job that gives you scope, not the one with the shiniest title. You'll learn more in twelve months at a chaotic NGO or SMB than three years at a bank where your role is locked down.
4. Start writing publicly. One LinkedIn post a week about what you built, fixed, or learned. Compound visibility beats quiet competence every time.
5. Re-evaluate at the two-year mark. By then you'll know whether automation, infrastructure, CX, or ops is the path you want to double down on. You'll have real data — not university predictions — to decide with.

The Bigger Point

Your CS degree is not a map to a developer job. It's a ticket into a much larger industry. Most of the interesting, well-paid, fast-growing corners of that industry are not called "software engineer." They're called operations, support, infrastructure, ops, automation, CX.

The fastest way to get stuck is to assume there's only one door. There are many, and most of them have shorter queues than the one you've been told to stand in.

If you're trying to figure out which door is yours, get in touch. I've had this conversation with enough people to know it usually only needs one honest external perspective to shake loose.