What Makes a Good IT Professional

More than technical knowledge

Most job adverts in IT list technologies: Windows, Linux, networking, a cloud platform, a scripting language. Those matter, and the other topics in this encyclopedia cover them. But ask a team lead what makes a new colleague good, and the answers are usually about something else: "she tells me when she is stuck", "his ticket notes are clear", "he does not leave things half done", "she stays calm when the phones go mad".

These working habits are often called soft skills: communication, collaboration, reliability, judgment, handling pressure and learning. The name is unfortunate, because there is nothing soft about them. They are skills in the full sense — you can be bad at them, practice them and get noticeably better — and in IT they have hard consequences: a vague handover note can turn a one-hour outage into a four-hour one.

Technical and working skills also reinforce each other. A methodical troubleshooter (see a structured troubleshooting method) learns faster, because every problem leaves a clear lesson. A clear writer gets better help, because people understand the question. This topic is about those habits, one page at a time.

Ownership

Ownership means treating a problem you have touched as yours until it is solved or clearly handed to someone who has accepted it. It does not mean doing everything yourself. It means the thread never drops: no ticket sits in a queue with nobody looking at it, no user waits without knowing why, no "I thought someone else was on it".

Compare two notes on the same ticket. A user at Kestrel Energy cannot open the meter-reading report; Amara Okafor on the service desk finds that the report server belongs to the billing team.

INC-20417
Not a service desk issue. Report server is billing.
Reassigned to Billing.

INC-20417
User (finance, Rotterdam) gets "HTTP 500" opening the daily
meter-reading report since 08:10. Two colleagues on the same
team see the same error; other reports open fine.
Checked: user's access group unchanged, cache cleared, other
browser tried - same error. Looks server-side.
Reassigned to Billing (Joost Bakker confirmed by chat at 09:05
that they pick it up). Told the user: billing team is looking
at it, I will update her by 11:00 either way.

Both notes reassign the ticket. Only the second makes sure the next person can start where Amara stopped, that someone has accepted it, and that the user knows what happens next. The 11:00 promise is the important part: Amara still owns the relationship with the user even though she no longer owns the fix.

Reliability

Trust in IT is built from small, boring things: you are on time, you do what you said, and when you cannot, you say so before the deadline rather than after it. Users and colleagues forgive a slow fix far more easily than silence.

A useful habit: every time you tell someone "I will get back to you", attach a time, write it down, and keep it — even if the update is "no news yet".

Hi Lucía, as promised a 15:00 update on the invoice export
(INC-20433): the billing team has reproduced the problem
but not found the cause yet. Your workaround (export per
region) still works. Next update tomorrow 10:00, or earlier
if it is fixed.

Reliability also means finishing. A fix is not done until it is verified with the user, the ticket is updated and, where it helps the next person, a knowledge article exists. The details of good ticket writing are on writing tickets and technical documentation.

Curiosity, within boundaries

Good IT people want to know why. Why did restarting the service help? Why only on Mondays? Why does this one laptop take four minutes to boot? Curiosity turns a recurring incident into a found root cause, and it is the engine of learning on the job.

Curiosity has boundaries, though. Admin rights give you technical access to mailboxes, home folders and databases full of personal data; they do not give you permission to look. The ACM Code of Ethics puts it plainly in principle 2.8: "Access computing and communication resources only when authorized or when compelled by the public good." Be curious about how systems work, not about what is in other people's files. More on this in ethics, privacy and professional conduct.

Curiosity should also not become experimenting on production. "Let me just try this" on a live system is how a small incident becomes a big one. Try it in a test environment, or follow the rules on working safely on production systems.

Knowing your limits

Starters often worry that escalating looks weak. In practice, the opposite is true: people who escalate early, with a clear summary, are trusted more. The ACM Code says it in one line, principle 2.6: "Perform work only in areas of competence." That is not an instruction to stay small — you grow your competence deliberately — but a warning against guessing on systems you do not understand.

A good escalation tells the next person what is going on, what you have already ruled out, and what you need. Compare:

@Tomasz the VPN is broken again, can you look?

@Tomasz VPN question, INC-20451. Since about 13:30 three field
engineers (all on the Groningen region profile) connect but
cannot reach any internal site. Others on other profiles are
fine. I checked their accounts and certificates: valid.
I think it is on the gateway side, which I cannot see.
Can you check the Groningen profile? The engineers have a
workaround (mobile hotspot + webmail) for now.

The second message takes two minutes longer to write and saves Tomasz twenty minutes of asking the same questions. How escalation is organized — functional and hierarchical, and the support tiers — is explained on the service desk.

Broad and deep: T-shaped skills

A person with T-shaped skills has a broad base of working knowledge across many areas (the horizontal bar of the T) and real depth in one or two (the vertical stem). In IT, the breadth lets you follow a problem across team boundaries: a "slow application" might be the network, the database, the disk or the code. The depth makes you useful: you are the person who actually knows how the firewall rules work.

Two practical consequences. First, early in a career, breadth comes from rotating through problems — the service desk is an excellent place for it, because everything passes by. Second, depth comes from choosing: you cannot be deep in everything, and pretending to be makes you shallow everywhere. Career paths and how to choose a direction are on building your career in IT.

Learning and confidence

A growth mindset

A growth mindset is the belief that abilities develop through effort, good strategies and feedback, rather than being a fixed talent you either have or lack. The term was popularized by psychologist Carol Dweck. How large its measurable effects are is debated in research, so treat it as a useful working attitude, not a magic switch.

In IT, the attitude shows in small sentences. "I don't know Kubernetes" becomes "I don't know Kubernetes yet — where would I start?" A failed change becomes a question about what to check next time rather than proof that you are not cut out for this. Technology changes so fast that everybody is a beginner at something every year; the people who do well are the ones who are comfortable being beginners. How to learn efficiently is on learning continuously.

Impostor syndrome

Impostor syndrome is the persistent feeling that you are less competent than others think, and that sooner or later you will be "found out" — despite evidence that you are doing fine. Psychologists first described it in the late 1970s as the "impostor phenomenon". It is not a medical diagnosis, and it is very common in IT, where the field is too big for anyone to know everything and colleagues talk confidently in acronyms.

Some things that help:

• Compare with your past self, not with the senior engineer. Keep a short "done" list: problems solved, things learned. Read it on bad days.
• Notice that seniors look things up too. Experience is often knowing where to look and which question to ask, not having everything memorized.
• Say "I don't know, I'll find out". It is a professional answer. Bluffing is what actually damages trust.
• Talk about it. A mentor or trusted colleague will very likely recognize the feeling. If self-doubt starts to affect your sleep or health, see health and sustainable work.

Working well with others

IT is team work across shifts, teams, suppliers and users. A few habits make you the colleague people like to work with:

• Write things down for the next person. Your future self counts as the next person.
• Give credit, take blame for process, not people. "Hamid found the index problem" in the team chat costs nothing and is remembered. When something goes wrong, ask what in the process let it happen — the approach behind blameless postmortems.
• Respect the user's time and intelligence. Users are experts in their own work. "Could you show me what you click?" works better than "What did you do?"
• Be predictable under pressure. Calm, short, factual messages during an outage help more than speed. See working under pressure.
• Disagree with the idea, in private if possible. "I am worried this change has no rollback plan" lands better than "this is a bad idea".

[ ] Know how to reach my team lead and the on-call engineer
[ ] Know where tickets, the knowledge base and runbooks live
[ ] Every promise to a user gets a time, written in the ticket
[ ] Before escalating: what I saw, what I checked, what I need
[ ] Keep a "done and learned" list, five minutes each Friday
[ ] Ask before touching anything in production