Technical Skills Every IS Researcher Actually Needs

The IS PhD cohort I joined included people with computer science backgrounds, people with MIS undergraduate degrees, people who had spent years in industry as project managers or business analysts, and one person with a philosophy degree. The range was not unusual. IS departments draw from everywhere because the field itself sits between disciplines and does not enforce a standard entry profile. The consequence is that almost everyone arrives with a gap. The CS people know how to code but sometimes do not know organizational theory. The management people can run a survey but freeze when someone mentions a regression diagnostic. The industry people know practice but struggle with theory. And the philosophy person made everyone feel intellectually inadequate for two semesters.

I came in from a technical background, which meant my first gap was theoretical. But as I moved through the program and started doing actual research, I discovered the technical gaps that snuck up on me were more specific than I expected.

The most useful technical skill I have built is facility with R. I picked it over Python mainly because most quantitative IS research uses R-based tools, particularly for structural equation modeling. PLS-SEM is almost universally done in SmartPLS, but understanding what the software is doing, being able to run confirmatory factor analysis in R, check for common method bias, and handle multigroup analysis, makes you a much better researcher than someone who just clicks through a GUI. I can get the same outputs in Python, but the IS literature assumes R, the workshops at IS conferences teach R, and your committee members will expect you to know it. I would not fight that default.

The specific quantitative techniques worth learning are not as exotic as they sound. Regression basics: ordinary least squares, hierarchical regression, moderation and mediation. PLS-SEM for theory-testing surveys. Some text analysis basics if you work with online data: topic modeling, sentiment analysis, maybe some basic NLP. That last category has become much more accessible now that Python libraries do the heavy lifting, but you still need to understand what the model is doing well enough to explain it in a methods section. The one thing I would warn against is treating any of these as plug-and-play. The most dangerous IS researcher is one who knows just enough to run the analysis but not enough to spot when the data violates the model's assumptions.

For qualitative work, I have used NVivo and found it useful mostly for managing large volumes of coded data, not for generating insight. The insight still comes from reading. What NVivo does is help you keep track of the codes across dozens of interview transcripts without losing your mind. Atlas.ti does roughly the same thing with a different interface. If you are doing interpretive research, know at least one of these tools, but do not mistake software proficiency for methodological rigor. Klein and Myers' seven principles for interpretive research are what matter; NVivo just keeps the files organized.

SQL is underrated in IS PhD programs. Not everyone needs it, but if you ever work with organizational data, either from a company that has given you database access, a university records system, or a public dataset with relational structure, basic SQL saves hours. Knowing how to join tables, filter records, aggregate counts, and export clean datasets is the difference between spending an afternoon on data preparation and spending a week on it. I picked up SQL mostly by doing it badly for a while, and I would recommend any IS PhD student spend a few evenings with a tutorial before they need it urgently.

The more interesting question, and the one that creates the most tension in IS PhD seminars, is whether IS researchers need to code at all. My honest opinion is: it depends on what you study, and the people who say "yes, everyone needs Python" are wrong in the same way as the people who say "we are a social science, coding is not our job." If your research involves machine learning models, large-scale text data, or any artifact analysis at the software level, you need to code. If your research involves organizational case studies and your data is interviews and documents, you do not need Python, and pretending otherwise is just credentialism.

What I think IS researchers do need, regardless of method, is enough technical literacy to understand what practitioners are talking about. When someone at a company says they are having trouble with their ERP integration, you need to understand what integration means in that context and what kinds of problems it creates. When someone describes their machine learning pipeline, you should know what training data, feature engineering, and model evaluation mean at a conceptual level. You do not need to be able to build the system. You need to understand it well enough to ask the right questions about it.

This is where familiarity with enterprise systems matters. SAP is the system I have encountered most in IS research on ERP and business processes. Salesforce comes up constantly in CRM and sales force automation research. ServiceNow appears in IT service management studies. I have not implemented any of these, but I have read documentation, watched tutorials, and spent time with practitioners who use them. That baseline familiarity is enough to follow what someone is describing in an interview and to catch it when they use a term in a way that does not match what the system actually does.

The trap I see IS researchers fall into is over-indexing on whichever technical skill got them into the program. The CS person keeps coding their way through problems that need theory. The survey researcher keeps building questionnaires when the question actually calls for fieldwork. Technical skills are tools. The research question should choose the tool, not the other way around.