"No. This is for techies. I am a humanities person." Sound familiar?
A single label, born out of a love for languages, history, or literature, suddenly dictates the professions you even allow yourself to consider.
But IT has long ceased to consist only of people who write code. And even where technical knowledge is truly required, "I don't know this yet" and "I am incapable of understanding this" are not the same thing at all.
So the question should be framed differently. Not "Am I a technical enough person for IT?", but "Which IT role matches the way I think, work, and solve problems?"
First, let's clarify: who exactly is a "humanities person"?
Usually, this word hides a set of beliefs something like this:
- "I'm not good at math."
- "I've never programmed."
- "I don't have a technical degree."
- "It's easier for me to work with people and texts than with formulas."
But a profession is not a high school division between those who loved algebra and those who wrote good essays. In the workplace, other things are much more important:
- how you structure information;
- whether you can figure out a new system;
- how you find the root cause of a problem;
- your ability to ask the right questions;
- how you communicate with other people;
- your attention to detail;
- whether you can explain complex things in simple terms.
And here's the interesting part. Some of the skills people are used to calling "humanities" are not a hindrance in IT — they are essential.
IT is not a single profession
When someone says "I want to work in IT," it's a lot like saying "I want to work in medicine." As what exactly? Developer? Analyst? Tester? Project Manager? UX/UI Designer? Product Manager? Technical Writer?
All these people might work on the same product, but their daily tasks and required skills will be entirely different.
Therefore, if you opened a Python course, understood nothing, and decided that "IT is not for me" — you might have just tried on the wrong profession.
Let's look at a few directions:
Business Analyst: if you like figuring out "what is actually needed"
Imagine a client comes to the team and says: "We need a system that automates our managers' work." That's not enough for developers. What exactly needs to be automated? Who will use the system? What is the current process? Where does it break? What data is needed? What should happen after clicking a button?
A Business Analyst turns "we want something like this" into requirements the team can actually work with. This requires an understanding of technology. But it equally requires the ability to listen, ask questions, see the logic of a process, handle large volumes of information, and explain the same idea to both the business and the technical team. Thus, experience in communications, education, marketing, management, or working with texts may turn out not to be an "irrelevant past," but a solid foundation.
Project Manager: if it's natural for you to turn chaos into a system
Where are we now? What is blocking the team? Who depends on whom? Why is the task planned for Wednesday still not done? What happens to the project if this deadline shifts?
A Project Manager is not required to write code instead of a developer. But they must understand the development process well enough to coordinate people, risks, timelines, and priorities. Systemic thinking, communication, responsibility, and the ability to keep track of many interconnected processes are especially valued here. If you are the person in a group project who subconsciously starts assigning tasks, bringing everyone together, and asking "so, what's our plan?" — you should look into this direction.
QA: if you notice things others walk right past
A developer sees a registration form and thinks: "It works." A QA looks at the same form and asks: What if I leave the field blank? What if I paste 300 characters? What if I click the button twice? What if the user loses internet connection mid-process? What if I enter an invalid data format?
Testing is largely the ability to look for scenarios that others haven't thought of. Yes, QA also works with technical tools, documentation, APIs, and in automation — with code too. But at the start, attention to detail, logic, curiosity, and the habit of asking "What happens if...?" play a huge role.
UX/UI: if you're interested not just in "beautiful," but in "clear"
Why can't the user find the right button? Why do they abandon checkout at step three? How do you organize information so the person doesn't have to think about where to click next?
UX/UI is not just about choosing colors and pretty fonts. It is work at the intersection of design, human behavior, product logic, and business goals. Therefore, the ability to understand context, work with meaning, and look at the product through another person's eyes can be a serious advantage here.
What about programming? Is it strictly off-limits for humanities people?
It is allowed. Just here, it's important not to fall into the other extreme and promise that programming will suit absolutely everyone.
To become a developer, you will have to study algorithms, data structures, language syntax, databases, architecture, and much more. In certain areas, math will also be needed.
Programming is not about constantly solving complex equations. A significant part of a developer's job is to understand a problem, break it down into smaller parts, find patterns, and consistently build a solution.
So instead of: "I have a humanities mindset — will I be able to do this?"
it is more useful to ask: "Do I enjoy the process of solving such tasks enough to be willing to study this?" And this is something you can test.
But there's a nuance: "non-technical profession" doesn't mean "no need to know technology"
Here is where another extreme often arises. A person hears that a Project Manager or Business Analyst might not code, and concludes: "Great. That means I don't need the technical part at all."
Not quite.
- You don't have to write the backend to understand what an API is.
- You don't have to be a DBA to know the basic principles of how databases work.
- You don't need to deploy the product yourself to understand the difference between frontend and backend, and what roughly happens between an idea and a release.
Your level of technical depth will depend on the profession. But working in a tech environment and fundamentally refusing to understand technology is a bad strategy.
Maybe the problem isn't that you are a "humanities person" at all
Sometimes, the phrase "I'm a humanities person" hides something entirely different: "I'm afraid of feeling like a beginner."
In your current profession, you already know the terms, rules, and context. You can sustain a professional conversation. You know what to do when a problem arises. And then you open an article about IT and see: repository, endpoint, framework, pull request, sprint, deployment…
And suddenly you know nothing again. It's an unpleasant feeling. But it doesn't mean you have the "wrong brain." It means you've entered a new professional field. Every specialist once didn't know what an API was.
How do I know which direction is mine?
Don't start with the question "Where are the highest salaries right now?". First, look at the type of tasks you will have to deal with every day.
If you like…
- dismantling needs and structuring information → look into Business Analysis;
- organizing people and processes → Project Management;
- looking for errors and testing scenarios → QA;
- researching human behavior and designing interactions → UX/UI;
- building logic and creating solutions through code → Development.
But don't choose a profession based solely on this list. Look at a few real job descriptions. Open a training syllabus. Try a basic practical task. See what the work actually looks like, not just how it's described in a motivational post.
You don't have to decide right away what you'll be doing for the next ten years. At first, it's enough to figure out: do I want to take the next step in this direction?
One more thing: your previous experience does not get wiped out
Career switchers often view transitioning to IT like this: "I'm 30. I've worked in marketing for five years. Now I have to start all over again."
But you aren't starting from scratch. You are starting without experience in a specific IT role, but with professional experience already under your belt.
- A Marketer might understand clients and business metrics well.
- A Teacher can explain complex topics and structure information.
- A Journalist knows how to ask questions, work with sources, and quickly dive into a new topic.
- A Manager coordinates people, deadlines, and responsibilities.
- A Financier works with data and business logic.
The question isn't how to hide your "wrong" past. The question is which part of this experience can be transferred to a new profession, and which competencies you still lack.
So, is there a place for a humanities person in IT?
In short — yes.
But not because "IT suits everyone." And not because you can find a profession where you won't have to deal with anything technical at all. But because dividing people into "humanities" and "techies" is too primitive for the modern job market.
IT needs people who write code. And people who understand users. Those who analyze requirements. Those who find bugs. Those who organize the process. Those who turn a complex system into an understandable product.
So the main question is not: "I'm a humanities person. Will they take me in IT?"
But: "What can I already do, what role do I want to perform, and what do I need to learn to transition into it?"
This is the question you should start your career switch with.
Don't guess the profession — find your direction
If you want to transition to IT but don't yet understand which role matches your experience, strengths, and goals, you don't have to find the answer on your own through trial and error.
At a SkillsUp career consultation, you can work with an expert to break down your experience, identify your strengths, evaluate potential transition paths, and form a realistic plan of next steps.
This is an opportunity to move from an abstract "I want to be in IT, but I don't know where" to understanding which professional trajectory might suit you specifically. Perhaps your humanities background is not a reason to give up on IT. But rather, exactly what will help you find your place in it.