Three Rules for Choosing a Technology Career
How to think about the choice when the standard path no longer reliably works.
Foreword
The path that worked through most of the previous decade — pick any reasonable engineering specialty, get hired into a junior role, learn the rest on the job — does not reliably work in 2026. The market has shifted. The kinds of work AI absorbs cleanly have shrunk the entry-level pipeline in those areas, and a generic technology degree no longer maps to a generic technology job.
What follows is not advice about which specific career to pick. It is advice about how to think about the choice. Three rules, each grounded in conditions visible today, that hold across most of the categories where technology work remains durable.
Want more practical data engineering analysis like this?
Join DWHPro Letters and get field-tested notes on Teradata, Snowflake, AI, migrations, performance, and enterprise data work. Early subscribers keep launch access before the paid plan launches.
Rule 1: Choose Work That Has Real Consequences
When asking which kinds of work hold up against AI, the most durable answer is not a particular language or framework. It is a property of the work itself.
Will somebody be held accountable when the system gets it wrong? Does an error in this work cause something measurable to go bad — a regulator's question, a financial loss, a safety incident, a security breach, a piece of physical hardware failing? Or is the worst case that someone has to refresh the page?
The work that involves real consequences is harder to fully automate, for two reasons that have nothing to do with technology. The first is legal: many regulated environments require a named human to be accountable for outputs, and an AI system cannot fill that role. The second is economic: when mistakes are expensive, organizations are willing to pay people they can trust to catch them.
These points move juniors away from categories most exposed to AI displacement and toward categories that have, until recently, been considered less glamorous. Banking and insurance, where regulators ask specific questions and require specific answers. Healthcare and pharmaceuticals, where errors affect real patients. Cybersecurity, where someone is actively trying to cause damage. Operational technology, where physical reality enforces correctness. Defense and government, where the consequences of error are large enough to be visible from far away.
The trade-off is real. These categories may pay less than equivalent roles at consumer technology companies, and the work is often slower-moving. What they offer in exchange is that the entry path remains open, the work is harder for AI to absorb, and seniority value compounds because the institutional knowledge required to do the work well is genuinely scarce.
For a junior making the choice today, a graduate program at a tier-one bank, an insurer, a regulated utility, a hospital system, or a defense contractor is, on the available evidence, a stronger long-term position than a similar-titled role at a consumer-facing technology company. The conventional wisdom to the contrary is based on conditions from the previous decade, which no longer hold.
Rule 2: Specialize Early in a Durable Category
The career advice of the previous decade favored breadth. Pick up multiple frameworks. Learn full-stack development. Be the person who can do a bit of everything. The argument was that flexibility beat specialization in a fast-changing field.
That argument no longer applies, and the labor market has reversed. Domain experts now command pay premiums that generalists do not. Most senior-track postings explicitly ask for specialists. The reason is that AI tools have absorbed the cost of being a generalist. If the work is "a bit of frontend, a bit of backend, a bit of database," then an AI assistant can do all of those things at the level of a competent junior, faster and cheaper. The value a generalist adds is whatever is left after subtracting what AI can do, and the residual is small.
If you work with enterprise data platforms, migrations, performance tuning, or AI-driven delivery teams, DWHPro Letters is written for you. Get the next issue by email.
For a specialist, the calculation reverses. Deep knowledge of a specific domain — how a particular regulatory framework actually works, how a particular class of hardware fails, how a particular kind of attacker operates, how a particular industry's data is actually structured — is exactly the kind of knowledge AI does not have unless someone provides it. The specialist's job becomes directing AI rather than competing with it, and that role pays well.
The advice for a junior is direct: pick a specialization early, pick one in a category where the work itself is durable, and commit. The cost of picking is much lower than the cost of waiting. Years spent becoming genuinely competent in one domain compound. Years spent dabbling across many do not.
The criteria for a good specialization are straightforward. The category should be one where work has real consequences. The specialization should require knowledge that takes time to acquire and does not appear in an obvious form on the public internet. It should sit close to a regulatory regime, a hardware constraint, an adversary, or a physical system. And it should be a category the candidate can stand to spend many hours in, because depth requires hours.
The categories that meet these criteria are not always the most prestigious-sounding. Industrial automation. Insurance core systems. Hospital infrastructure. Banking regulatory reporting. Power grid operations. Defense communications. None of these will get a hiring manager excited at a coffee shop in a tech hub. All of them have greater long-term durability than typical consumer technology products.
Rule 3: Build Proof, Not Credentials
The third rule overturns most existing advice.
Until recently, the standard path was to acquire credentials — a degree, then certifications, then a portfolio of practice projects — and use those credentials as evidence of capability. Hiring managers relied on credentials as a filter because they had no better signal.
That logic has stopped working. A bootcamp portfolio of cloned projects shows nothing that an AI tool could not produce in an afternoon. A computer science degree from a credible university is now a baseline expectation, not a differentiator. Certifications that used to signal expertise are increasingly treated as table stakes, if noticed at all.
What has replaced credentials is evidence of operational responsibility. is a system with real users, an artifact with a documented failure mode, a project that has been running long enough to have broken at least once and been fixed. Hiring managers read such evidence carefully because it answers the question credentials do not: can this person take responsibility for an outcome?
For a junior without a job, this presents an obvious problem. How does one build operational evidence without first being hired? The answer is to find a problem that someone other than the candidate actually has, and solve it in a way that produces a small, real, ongoing system. A volunteer organization that needs better infrastructure. A small business that has not modernized its workflow. A research group that requires a tool nobody has built. The system built does not need to be impressive. It needs to be real and keep running long enough for the candidate to have learned something from operating it.
The kinds of evidence that count are recognizable. A small security tool with a documented threat model and a record of issues it has caught. A piece of embedded software running on real hardware with measured power consumption. A small AI system with documented failure modes and an evaluation harness. A data pipeline running in production for someone other than the author. None of these needs to be at the scale of a large enterprise system. All of them need to be real, in the sense that they exist in the world and have been operating long enough to teach the candidate something.
The shift is from "I have learned X" to "I have built Y, and here is what I learned by operating it." The first is a credential. The second is proof. In 2026, only the second compound.
Closing
The three rules above do not tell anyone what career to choose. They describe how to think about the choice in a market where the previous heuristics no longer work. Choose work that has consequences. Specialize early in a durable category. Build proof rather than credentials.
A candidate who follows all three of these will not necessarily have an easier time finding a first job than a candidate who follows none of them. The first job is a function of timing and luck, and neither rule changes either factor. What changes in the rules are the trajectory after the first job? The candidate who follows all three is on a track that compounds, in a category that holds up, with evidence of capability that matters. Five years later, the difference will be substantial. Ten years later, it will be the difference between a stable senior career and a constant struggle to stay employed.
The choice of how to enter technology is one of the most consequential a young person will make, and the dominant career advice does not yet reflect the conditions that actually exist. The three rules above are an attempt to describe what does.
Trying to understand what AI means for data engineering work?
I write about the parts of IT work that are actually changing — and the parts companies still misunderstand.
Subscribe before the paid plan launches and keep launch access.
Written by Roland Wenzlofsky, founder of DWHPro and author of Teradata Query Performance Tuning. DWHPro has helped data warehouse practitioners for 15+ years.