What IS PhD Programs Teach and What They Don't

I want to be upfront that this is a personal post. I am not speaking for any program, any department, or any advisor. What I'm writing here is what I have noticed going through an IS PhD program at UNT, and what I think is worth saying honestly, because I don't see it said often enough in the places where prospective PhD students might find it.

PhD programs in information systems are genuinely rigorous. The theory coursework is real and demanding. Learning to read research critically, to identify what a study can and cannot claim, to trace an argument from literature to hypothesis to findings and back again, these are real skills that take years to develop. I don't want to minimize that. But there are gaps between what the curriculum covers and what doing IS research actually requires, and some of those gaps are large enough that I think they're worth naming.

The biggest one, in my experience, is writing. Not writing in the sense of grammar and sentences, but writing in the sense of audience, purpose, and genre. The PhD curriculum teaches you to write for journal reviewers. You learn the structure of a quantitative IS paper, the way a theoretical model is introduced, the way methods are described, the way findings are framed relative to prior literature. That is one genre. But IS research is supposed to matter beyond that single audience. Writing a policy brief is different from writing a journal article. Writing for a practitioner magazine is different again. Writing for a public blog or a general audience is different still. Almost none of that gets taught, or even discussed. The implicit message is that the journal paper is the only output that counts.

The methods training has a similar narrowing. Most IS PhD programs are heavily weighted toward quantitative survey methods. Partial least squares, covariance-based SEM, factor analysis, scale development and validation. These are real and important tools. But they are not the whole toolkit for studying information systems, and the problems that matter most in IS don't always fit neatly into a survey-based variance model. Qualitative methods get some attention, usually one course, often taught as a secondary track for people who couldn't make their quantitative model work. Design science gets less attention than I think it deserves. Computational methods, text analysis, process mining, simulation, are typically optional add-ons rather than core curriculum. The result is that most IS PhD students become competent at one methodological tradition and underprepared for the others.

The theory diet is another gap. The foundational theories are covered well. TAM, DeLone and McLean's IS success model, Orlikowski's structuration work, institutional theory applied to IS adoption. These are genuinely important. But the curriculum gets thin when you move toward the questions that practitioners are actually facing. AI governance and accountability, platform ecosystems and their political economy, algorithmic decision-making and fairness. These topics don't fit neatly into the theoretical frameworks that IS PhD training tends to center. Students who want to research them often have to do a lot of independent reading outside the assigned curriculum to find frameworks that fit.

The one that nobody talks about is rejection. Academic publishing involves a lot of rejection. The review process for IS journals is long, the acceptance rates are low, and the feedback can range from genuinely helpful to confusing and contradictory. You can do solid work, get two positive reviews and one hostile one, and end up with a rejection that doesn't give you a clear path forward. The emotional experience of that process is real and hard, and PhD programs generally don't prepare you for it at all. The implicit cultural message seems to be that rejection is just part of the process, and you should develop a thick skin. That is true as far as it goes, but it leaves people to figure out on their own how to stay motivated, how to revise without losing confidence, and how to navigate feedback that is genuinely unclear about what it wants.

The practitioner connection is the last gap I want to name. IS as a field exists at the intersection of technology and organizations, and the argument for why it matters is usually that it produces knowledge useful for organizations that design, adopt, and use technology. But the connection between what IS PhD students study and what IS professionals in organizations actually need is often thin. The theories and constructs developed in IS research don't always translate into actionable guidance for the CIO trying to decide whether to migrate to a new cloud architecture, or the IT manager trying to figure out why the ERP implementation isn't going well. Some IS research makes that translation. A lot of it doesn't, and the PhD training doesn't emphasize the translation work as part of the researcher's job.

I am not saying any of this means IS PhD programs are failing. The rigor they produce is real. The skills they develop are valuable. But the gaps I've described are real too, and the students who navigate the program most successfully seem to be the ones who find ways to address those gaps on their own, by writing in different venues, by learning methods outside their home tradition, by staying connected to practitioner communities even when the academic incentives don't reward it. That suggests the gaps are structural, not accidental. They reflect choices about what the curriculum prioritizes, and those choices are worth examining.