practical phd

a transparent source for all things PhD

Writing is never a straightforward process, and particularly so for academic writing.  While we read articles from introduction through to conclusion (the first page to the last page), this is not how articles are written.  Nor dissertations or books for that matter.  The key to successful academic writing is embracing the irregularity of and iterations in the process.

Irregular Writing

Why?  Because writing an article (or book or dissertation) from start to finish means writing about how your study contributes before you’ve written about your findings (the contributions).  Research that is written from start to finish almost always suffers from a disconnect between the front end (introduction and literature review) and back end (findings, discussion, and conclusion).  The front end promises answers to questions and engagement with literature or theory that then the back end does not follow through on.

Embracing irregular writing means starting to write in the middle.  Data and methods sections are an easy place to start to get your writing flowing, but most important is making sure you draft your findings section(s) before any other section of an article or chapter.  You need to know your findings in order to identify what literature or theory you need to set them up.  You even need to know your findings to formulate accurate phrasings of your research questions in your introductions.

Irregular writing also happens within sections.  I never write an introduction paragraph to a section before I draft that section.  Writing the section first lets me see what I’m actually saying in that section and then write an accurate introduction paragraph, rather than a hypothetical one.

Iterative Writing

The other practice I find helpful is the repetitive process of writing in iterations.  Approaching writing as an iterative process means layering in more writing in distinct stages rather than all at once.  This involves visiting and revisiting the same writing not with an eye for editing, but with an eye for adding to the text.

For example, I’m currently working on a findings section from an extensive quantitative analysis that includes subgroup analyses.  My first iteration was to go through and simply write a sentence about each significant finding for a subgroup.  My second iteration was to add sentences that provided interpretation and analysis to the reader for each finding.  I finalized each section with an irregular writing technique of writing the introduction summary paragraph for the section on the subgroup.

Using an iterative process lets me start with the evidence and build out what I want the reader to take from the evidence, while I engage with the evidence multiple times.  It gives me some time to sit with a finding and decide whether the results for income and education suggest a pattern around socio-economic status that I want to impart to the reader or if each separate variable suggests something slightly distinct.

Remember, writing is thinking!  Irregular and iterative writing processes help embrace the thinking part of the process.  As you approach new sections and revisit drafted ones, you apply what you’ve learned (through writing as thinking) to continue to develop your manuscript.

After doing most of my qualitative data analysis solo during my time as a graduate student, I have spent the last 7 years readapting to coding in teams.  Unlike many of my fellow sociologists, I began as a qualitative researcher in a team-based setting.  In evaluation research, I worked with as few as 2 and as many as 5 other researchers with varying degrees of prior experience to code qualitative interviews, focus groups, observation notes, and supporting documents.  The experience of being on those teams and my more recent experience leading teams through the process have brought to light key insights about working with teams for qualitative coding.

Conducting qualitative coding with teams is challenging because of the subjective or interpretative nature of a lot of coding.  Most projects do include codes that are straight forward and explicit, capturing direct and explicit mentions of a topic, person, organization, program, idea, or feeling, but these codes are only part of most analyses.  Many of the questions researchers have involve codes that require interpreting what our documents say in order to put like passages together across documents where language may be quite varied. 

This interpretation process makes it challenging to produce consistent results in group coding.  Some researchers take the approach of reliability by having more than one team member code every document and produce a score that captures how similar their coding is as proof of consistent results.  But that approach is not always possible due to the resources required, particularly with larger qualitative datasets, varied access to Qualitative Data Analysis software, and differences in deadlines for final products.  Instead, I have approached the process of group coding with 5 strategies that ensure consistent coding results across my team.

  1. Documenting the coding scheme.  All of my projects have a codebook.  These include the name of the code, a definition of the code, notes on any exceptions or universal application of the code, and sometimes a sample quote where the code would be applied.  In some cases, I include specific words or phrases that indicate that the code should be used.  Similarly, for exceptions or universal applications, I flag where the code should never be applied (e.g., never with X code, never when a Y person/place/thing is mentioned), and where the code should always be applied.  The codebook is a living document that is continuously updated based on feedback and discussion with the team, so I also keep a “date last updated” at the top of the document so everyone is aware of whether they are working with the latest version of the codebook.
  2. Test coding as a team.  Along with the codebook, I train the team with test coding the same document or 2 together.  We then meet to discuss and compare our coding, as well as review any questions that surfaced while doing the coding.  The comparison part of this process always surfaces different interpretations of the same codes from either the lack of application of a code or the application of a code to very different passages.  These differences provide the fodder for a conversation about how team members understand the codes and lead to an agreement on how to interpret the codes.  These clarifications are written up in meeting notes and then added to the codebook as a reminder to the team.
  3. Regular team meetings.  Once test coding is completed and each team member has their individual coding assignment, I hold weekly team meetings to review questions.  I ask team members to bring specific passages with questions to the meetings including what codes they applied to the passage that they didn’t have questions about, which we all discuss.  While we always discuss the specific question that the team member had about their passage, seeing what other codes they applied to the passage also opens up new discussions about when we are applying code X or whether code Y should also be applied to the passage.  These are always a little tentative at the beginning as team members get comfortable with being vulnerable with each other, but with time and maintaining a supportive environment, everyone becomes used to bringing questions and concerns to the meeting.  Key to these discussions is uncovering the assumptions that each team member is bringing to their coding and making sure that we all get on the same page.
  4. Continuous review.  Because not all issues with coding will surface as questions, I also include paired coding assignments on a regular schedule such as every 10 documents where 2 team members code the same document and we discuss any differences in their coding.  This brings new interpretation differences to the table and can also highlight areas of the codebook that coders are overusing or underusing. 
  5. Cleaning the coding.  Once each team member has completed their coding assignment, they are tasked with cleaning their coding by revisiting the documents they coded early on in the process until they find that they are not finding any corrections to the coding.  Because our interpretation and consensus with the codes is evolving throughout the coding process, team members generally find that their early coding needs to be corrected to be consistent with their latest understanding of the codebook and the codes.  Based on meeting notes, you can also create a list of common errors for your coding team to review for based on changes to the codebook including additions and changes to definitions, and issues that arose in the coding question shares and the paired coding reviews.

With these 5 components, I find that my coding teams can reach agreement in their coding that provides consistency in the results despite having multiple brains involved in the process.

At the end of the term (fall, spring, and summer), I take about an hour to write down what I did in the term.  That’s everything from writing to teaching to service to mentoring. For each of these completed tasks, I answer four questions that capture what I accomplished, what I learned, what I want to keep, and what I want to change.  I find the exercise helpful for giving me a better sense of all that I have done over the course of the semester.  Because research work is ongoing and not always possible to finish within the confines of a semester, it’s sometimes hard to see progress.  For me, spending an hour reflecting on all that I have done by reviewing my old to do list helps me see that just because the projects aren’t finished doesn’t mean I was idle or unaccomplished.  It also gives me lessons for my future work that allow me to build on what I love about the work that I do as I move forward in this career.  

For example, here are the lessons from my spring 2025 semester:

  1. Making time for data analysis during the semester is possible.
  2. I enjoy being in the weeds of my data!  (YAY for coding!)
  3. I can write what I want to say.  I already know the literature for most of my projects well enough to do that.
  4. It’s okay to leave blanks on the page while writing, flagging things to figure out later.
  5. Leverage opportunities for existing projects instead of creating new ones.
  6. Bet on yourself!
  7. Take advantage of opportunities to build community and meet new smart people.
  8. Sometimes the best move for a revision is a big change.  It’s worth the time that it takes.
  9. Choose projects that you enjoy the literature about, not the ones that make you want to poke your eyes out while reading.
  10. Do service work that fills your cup.
  11. Challenge graduate students in their thinking, while being supportive of their ideas.
  12. Keep trying and putting yourself out there.
  13. Communication is central with any research collaboration.
  14. Support women of color researchers through service and citations.
  15. Look to create models you can replicate in mentoring and service.
  16. Putting the time in is more likely to get you the result you desire.
  17. It’s okay to stick to your lane of expertise and not extend yourself beyond that.

What lessons do you want to take from spring semester into the future?

So much of my daily work happens on the computer.  It’s where I write.  Where I read journal articles.  And even where almost all of my meetings happen.  I’ve had such a marked increase in time in front of the computer that I have been wearing blue light glasses regularly since around 2021.  I have been looking for ways to step away from the computer over the last year to counter this increase.  Some has come in making time for in person meetings, but the bulk of the change has come in the form of going analog. 

The research journal that I have previously written about here is an example.  I could have done the journal in a Word document or with an app.  Instead, I use a notebook and a collection of colored pens that now occupy a ziploc baggie.  (I’m in the market for a fun pencil case if you have recommendations.)  Writing by hand makes me slow down because honestly if I don’t I can’t reread what I wrote.  It also gives me space to randomly draw diagrams or chart out a timeline for a project.  

The other thing I’ve taken analog is book reading.  With the exception of books I only have access to on the computer through the library website, I am reading away from my computer.  While I have never been opposed to writing in books, I’ve started using 2 colors of small post its to flag passages I want to take notes on and footnotes or references I want to take a closer look at.  After I’ve reviewed the book, I sit down and take notes.  So far I’m finding my digitized notes are more curated.  Instead of typing out pages of full quotations like I do when I sit at the computer to take notes while reading, I have summaries of things that I know I can use the book as a citation for and more select extended quotes.  Reading away from the computer also means I can use the comfy chair in my home office more often, go sit outside, or pull out my book while waiting at my son’s soccer practice.  

Going analog forces me to slow down.  It gives me opportunities to change scenery.  And it helps me curate rather than compile everything and anything. 

If you’re interested in pursing a tenure-track job, there’s this thing you need to know about: the research pipeline. I never heard the phrase “research pipeline” in graduate school, but this is the concept behind advice like “always be publishing,” which I certainly did hear. It was only after graduate school as I got deep into advice for getting to tenure that the phrase came to surface, but it’s an important one to grasp and understand much earlier than on the tenure-track.

What is the research pipeline?

The basic idea behind the research pipeline is that you should always have more than one research project in the works at any time, but that these projects should be in different stages so that there’s always something next to submit for publication. The pipeline metaphor captures that you have ideas about future research, data that you’re collecting for specific projects, research that is in the data analysis phase, articles and book chapters that you are writing, and work that is under review on its way to being published. I’m not going to suggest any numbers here because advice is quite varied and at the end of the day it depends on how much research you’re expected to complete for tenure and promotion.

What’s misleading about the metaphor is that research is not always a linear path from idea to data collection to data analysis to writing to being published. In fact, a school of thought that I subscribe to is that you should be writing before you’re finished your data analysis because the writing informs the analysis process (think cycle rather than timeline). But there’s another reason that you may not experience research as a linear path from idea to publication. Let me demonstrate through an example. I have a project that is technically still in the data analysis phase. I have most of the dataset compiled and have done some preliminary analyses. But I also have a full draft paper for that same project. How did that come about? Because I submitted to a conference that asked for a draft paper, so I wrote one. Is it finished and ready to submit to a peer-review journal? Not at all! But it’s not strictly in the data analysis phase of the pipeline either. So while these categories suggest a linear process, you might find that actually you’re working in several phases of the same project at the same time and that is normal.

So why is the pipeline still useful? It can serve as a way to manage your research towards tenure. That is, you can set up your pipeline as the projects you would like to accomplish by your 5th year on the tenure-track and thus the publications that you hope to accomplish for tenure. Obviously the pipeline can and should have a life after that point, but it can be a useful tool to set goals and make a plan.

Where does the content of the pipeline come from?

The research projects that make up the pipeline may start for you on your graduate school journey, or may have started before then. That MA thesis you wrote for a terminal program before completing your PhD or on the way to your PhD may be the start of your pipeline, or maybe your dissertation is the first research project in the pipeline. But you may have other projects that you start and compile along the way. For instance, graduate seminar papers are a great way to explore new research ideas. Some of these you will abandon to pursue other ideas, but some may continue to spark your interest and lead to a full blown paper. Other research projects may come out of conversations with your peers or your advisor that leads to a collaborative research project. So while some of the projects that are in your pipeline may come out of formal requirements for your graduate education, others may surface in other spaces.

One activity that can help fuel the pipeline is to document your ideas. This can be a word document, hand written notes in a journal, or notes in an App like Google Keep. Regardless of where you do this, jot down research ideas as you have them. I like using a notetaking App because I can tag each idea with topic areas and then easily review all of my ideas around a specific topic when I’m ready. When I document ideas, I write down where the inspiration came from (e.g., I was reading Brandi Summers’ book Black in Place), paste in any quotations that sparked the idea or contribute to my thinking, and write down as much detail as I have on the thought at that time. Sometimes this means that I have a sentence or a question for an idea, and sometimes this means I have a whole single-spaced page of thoughts. Having this list gives me something to look back on when I’m deciding what research I’m moving out of ideas into data collection next.

Collecting data as you stumble upon it may also contribute to the pipeline. While some research starts as an idea about something you’re interested in, others come about because you found a dataset or a digital archive and you construct an idea based on what kinds of questions you can answer with that data source. Now this doesn’t mean you need to go to ICPSR and download all that it has to offer. But it could mean that when you’re reading an article and you’re intrigued by a publicly available dataset that it mentions, you might download it to explore further as you have time. Or that when you’re looking for one digital database on the library website and stumble upon another on a related topic that you bookmark the page and make a note to yourself to look at it in more detail later.

Again, research that is in the analysis and writing phases may come out of your MA research, writing from coursework, collaborative projects with peers or advisors, and your dissertation. One thing to keep in mind is that your dissertation may be multiple research projects. For example, my dissertation has become a book project, but also a series of articles that use data from the project. In fact, as I was writing my dissertation and focused on finalizing that product for my committee so that I could graduate, I kept a list of article ideas that used the same data sources to potentially pursue in the future.

What should your pipeline look like as a graduate student?

So clearly from the examples that I’ve shared, the pipeline starts in graduate school. Now this does not mean that you will be publishing everything you’ve ever written in graduate school. Keep in mind that it is okay to let some things go whether that is because the data are not available or because you are more interested in another topic. Rather it means that you’ll be starting to develop projects in these different phases (e.g., idea, data collection, data analysis, writing, and publishing) over the years that you’re in graduate school. What this looks like is going to vary dramatically by the kind of research that you do (e.g., primary vs. secondary data collection), the kind of researcher you are (e.g., prefer to push multiple projects forward simultaneously or focus on one at a time), and your access to and interest in working with collaborators, so I’m not going to suggest any numbers here. But what I will say is that even if your pipeline is solely made up of your dissertation, you should have pieces of the dissertation split up into different parts of the pipeline, and an idea about what your next project will be by the time you’re on the job market. In fact, this is often what ABD applicants write about in their job market materials: (1) their publications, (2) their in the works project (usually their dissertation and anything else they plan to publish from that data), and (3) a proposed next research project. This demonstrates the start to a research pipeline.

To end, I want to acknowledge that the reason that this is part of what graduate students should be doing is because of the heightened expectations around publishing to get a tenure-track job and to get tenure. This is maybe also why some of us don’t hear about the research pipeline as graduate students, because it wasn’t always required. Hopefully this post provides a better sense of what it is as a starting point for seeking out more resources on the topic.

One of my graduate students recently asked me about my research journal so thought I would share what I use it for.  I started one at the end of last spring semester with the idea to make space to reflect on research, but it has become so much more.  Here are the things I have been writing about in it:

  1. Reflections. This is the most common form and comes in several types.  Some reflection entries are spontaneous free writes about how things are going.  Sometimes I am reflecting on a specific practice or approach I am taking and whether it’s working or not.  After a conference, I might write about the experience or what I learned.  Some more structured reflections I’ve done include responding to a set of questions at the end of each week.  I also use reflections to check in on my emotional responses to research.  For instance, when I feel blocked in my writing, I journal to try to identify why. 
  2. Prompt engagement. A lot of the research process related podcasts, books, and newsletters I listen to and read offer reflection prompts.  I keep a running list of prompts I want to come back to on my phone and pull the ones I want to engage with when I have the time to write.  This has included a lot of great prompts from Cathy Mazak’s podcast and book, as well as the AcWriMoments newsletter. 
  3. Planning. While most of my planning and semester priorities are on my computer, I have found it helpful to put pen to paper to map out things. This has included timelines, to do lists, semester and yearly plans, and daily schedules.  Most of this has focused on research activities, but I have also written about boundary setting (so I have time to do my research work) and self care (so I am my best to do the work).  
  4. Organizing. I also map out my broader research pipeline in my journal.  Sometimes this is to look at the subject areas my research is covering and how each project connects to my research agenda.  But other times it is to explore the balance between sole authored, first authored, and on the team research projects.  I have also done this kind of journaling to map funders to research projects. 
  5. Brainstorming. My writing to document ideas has included potential collaborator lists, funding ideas, and new project ideas.  
  6. Problem solving. When I get stuck in a research project, my journal is a space to think it through or write it out if you will.  I have done this to work through an unclear piece of feedback from a reviewer, a puzzle in connecting seemingly disconnected literatures, and to nail down specific concepts. 
  7. Drafting. While I don’t draft content for my research writing or grant applications in my journal, I do draft things like tenets for my career and my academic mission statement.  These drafts are closely tied to thinking about my longer term career goals and vision. 
  8. Notes. Last but not least, I take notes on writing books and research process related podcasts and newsletters in the journal.  In some cases, this includes writing out quotes that stood out to me or responding to prompts. 

Regardless of what I am focused on, the journal gives me a space to unleash what is on my mind and think through some of the trickier aspects of maintaining a research pipeline with multiple moving parts.  While I have tried it in the past with a Word document, it’s been particularly helpful to have a physical book and a pen to move myself out of my typical writing form, slow down (or I can’t read what I wrote), and even change my work setting.  I’ve found it so useful, I’m already on my second book!  

Whether you are getting feedback from an advisor or mentor, a colleague or friend, or from a peer review, you are likely to end up with some piece of feedback that doesn’t make sense to you. I’m talking about the feedback to which you think “But I did that on page 10!” or “Why would they think that?” Now this could be the result of someone reading quickly as all of us are forced to do at times to keep up on feedback requests that we receive, but I find it shortsighted to blame the reader without further investigation. Here are 3 strategies I use when I have this reaction to feedback.

1. I reread the piece looking for anywhere I may have been less explicit about a point. Sometimes I think I’ve been clear when I’ve used vague language (e.g., the results are different (different how???)) or some kind of insider lingo (e.g., using a term with no definition). By identifying where that could have happened, I can make my point more explicit and hopefully avoid confusion with the next reader.

2. I look for places where I may need to repeat information so that readers remember important guiding points. For example, the empirical articles I write always have a data and methods section where I explain the data source, how I used it, and how I conducted analysis. Sometimes that section describes information that won’t be relevant for another 10-15 pages from when it was introduced. Thus a reader might get to that part of an analysis and not remember how I selected a subsample or defined a code or even what kind of model I ran. Briefly repeating the information when it’s relevant (or moving the relevant section) can make it easier for the reader.

3. If I do these things and am still baffled by the feedback, I turn to a second opinion. I ask a trusted colleague or mentor if they can give me fresh eyes on a problem and send them the comment along with either the full piece or the relevant sections to take a look and see if they can identify the issue. If they come back similarly puzzled, I feel more comfortable assuming the reader simply missed something reading quickly.

About a month ago, I realized I had stopped planning somewhere along my tenure journey.  With the pressure to produce, I was so focused on individual articles, I had lost sight of the big picture.  So I set out to fix that and get back to a systematic, strategic approach to my research work.

Strategic planning should be a regular part of our work.  Like a nonprofit or research center, academics have a vision and mission for their research work.  This means we need to take the time to define what we’re aiming to accomplish and assess how the work we’re doing and have planned fits into that vision.

In my planning process, I started with what Cathy Mazak calls an academic mission statement.  As Mazak describes, “The big idea here is to clarify and articulate your mission, then line up all your activities so that they are serving this mission.”  The mission is an overarching guide that should be used to organize the rest of your work.  Just as a nonprofit might have a mission to alleviate child poverty in the U.S. by 2050, you can have a mission that drives your work as an academic.  In fact, as Mazak talks about frequently on her podcast, you should use your mission to identify what work you should say yes and no to.  That was the first thing I did after crafting my mission statement by reviewing all of my research projects and ideas with the question “Does the topic align with my mission statement?”

While my mission statement focused on the kind of scholarship I wanted to produce, I was also thinking about my goals for how I wanted to produce scholarship.  Here, I thought about how I work best, drawing on Michelle Boyd’s writing metaphor and her book Becoming the Writer You Already Are.  For example, data analysis is the part of the research process that brings me the most joy, so while it may be necessary to outsource data analysis for some projects because I do not have time to do all of the data analysis, I would like to always have data analysis work to do myself to have those moments of pure joy in the research process.  

The other aspect of how I do research that I tackled was thinking about how research gets done.  Out of necessity to keep research moving forward towards tenure, I have taken on more solo research than I originally thought I would do as a faculty member.  In stepping back to plan for the future, I want to have a balance of research projects that (1) I lead, (2) I collaborate on with peers, and (3) I lead in a mentored research project with graduate students.

I’ve been thinking a lot about what a reasonable workload looks like moving forward.  Here, I turned to the common advice to tenure-track professors at research institutions to always have 2 articles under review at any time.  What isn’t commonly discussed is what the rest of your research pipeline should look like to accomplish this goal due to differences in how faculty approach the research process (see prior paragraph).  Without any clear guidance on this, I got stuck on this point for a bit.  I talked to my frolleagues (friend-colleagues) about what they thought they would need in the writing and data analysis stages to maintain a goal of 2 articles under review.  I also looked at my current research pipeline (which is frankly clogged with too much in writing stage) in search of an answer.  I landed on an answer that is personal to the kind of research that I do and aim to do, which is solo and collaborative with small teams of up to 4, and includes both article and book writing (I count each book chapter as an article): 2 articles under review (or chapters out for feedback), 3 in writing stage, and 3 in data analysis or collection stage.  To be transparent, this is not a tested ratio, so I cannot say whether it is effective or not, but I will see over time.  

With my mission statement, writing metaphor, thoughts on how I want to do research, and goals for my research pipeline, I wrote tenets for my research work and strategies for how to achieve each of them.  This included tenets like “Collaborations produce stronger research” with strategies like “Approach frolleagues about joining existing and future research projects,” so that each tenet has a clear list of strategies that I can use to implement it.

This process is experimental and on-going, so the last thing that I have implemented, and perhaps the most important, is reflection and revision.  I started a research journal where I work through each of these parts of the process, reflect weekly on how the changes I’m trying to make are going, and think through new parts to this strategic planning process as I realize the need for something else.  

How are you reflecting on your research process and goals?

As I worked on the first article I submitted for peer review, I was given the advice to submit my draft article to a journal to get more feedback.  The logic was that I had workshopped the paper with several experts and it would be helpful to get fresh eyes on the paper.  Submitting it to a journal for peer-review would provide additional feedback from a different group of experts in the area.  I’m not sure how common this kind of advice is, but I’m sure some of you have heard this before.  So should you use peer-review to get feedback?  Ultimately, the choice is yours, but let me share a few things I didn’t know about the process at the time I was given that advice to help you decide what to do.

First and most importantly, getting rejected from a journal means that you have eliminated that journal for eventual publication of your article.  Most journals have a clear policy that they will not accept rejected articles because of the volume of submissions that they receive.  So if you submit to get feedback and receive a rejection, your article is permanently rejected from that journal.  This is important to take some time to think about because there are only so many appropriate journals.  For instance, I do research in urban sociology that is relevant for journals like City & Community, Urban Studies, and Urban Affairs Review.  If those three journals are the best fit for my article and I submit to one of them and get rejected, then I am down to two journals left.  Two journals may be plenty, but sometimes you need three (if not more) journals to find the trifecta of journal fit, editor support, and supportive reviewers to get your article placed.  If the article you’re working on is speaking to a very specific audience and has very few venues, it isn’t ideal to eliminate an option to get feedback.  

Second, even if you have a long list of journals in which you could publish your article, you may have preferences about what journal you would like it be published in.  This means that you should think carefully about where you would like to send the article to get additional feedback and not include the journal(s) that you are most excited about.

Third, submitting to a journal does not mean that you will get peer review.  Depending on the quality of the article and the fit with the journal, you could get a desk rejection, which provides you with little to no feedback on what you’ve written.  In my experience, most desk rejections are form letters that basically say the article wasn’t a good fit for the journal.  Occasionally, editors provide a little more information like “we don’t publish quantitative studies” or “the paper’s framing was too underdeveloped.”  The former comment is less helpful for revising an article to improve it for the next submission, but the latter comment provides some (although vague) direction on what to work on.  

Finally, it’s worth considering what other options you have for feedback.  You may not be able to ask the person who suggested that you submit it to get additional feedback, but you’re likely to have some other options at your disposal.  Consider sharing the paper with a workshop, a writing group, or other experts in the field.  I use the word “experts” broadly to not just reference someone familiar with the literature that you’re in conversation with, but to also include the prolific article writer who is not an expert in your subfield.  The prolific article writer knows how to formulate a journal article and can provide feedback on where your article does not follow important conventions you may not be aware of.  Think of these kinds of other options and figure out if there are any that you haven’t yet exhausted that could be used instead.

At the end of the day, whatever choice you make should be what is best for eventually publishing your work.  So weigh your options carefully in deciding when to click submit.

I’m not someone who sets resolutions in a new year. I’ve found that I rarely achieve resolutions and often feel guilty and unaccomplished upon reflecting on that failure. Instead, I like to set themes and intentions for the year to come. For my research work this year, my intention is to tackle the book project that has long been on the back burner behind many articles. 

When I first finished graduate school, I spent time learning about the book publishing process and thinking through whether I wanted my dissertation to become a book or a series of articles. I went to panels with book editors (they were incredibly helpful!!), talked through the dilemma with mentors, asked friends who had made a decision how they came to their choice, and talked to my new colleagues about what would be best for my tenure track journey. Based on the intel, I ended up pursuing a tenure plan focused on articles with the promise to myself that the book would be a post-tenure project. Over the years, the book has come to the front burner a few times as I have worked on the book proposal as a way to envision the pieces of the book and the broader argument, new data analysis that I’m integrating throughout the empirical chapters, and rough first drafts of some chapters to take a stab at what I want the chapters to look like. But the bulk of my research time has been focused on articles to make sure I’m meeting my goals for tenure.

This year marks the first time that I’m close enough to my tenure goals to think about my post-tenure research pipeline. (This is both scary and exciting.) Soooo…I have declared 2024 to be “the year of the book.” The challenge is that I still have a number of articles at various points in my research pipeline. That work is not coming to a stop partially because some articles are still in the review process and partially because they include a number of collaborative projects that need to keep moving forward. The point of declaring 2024 “the year of the book” is to make sure that the book stays at the top of my to do list. To make sure that even when I need to turn my attention to an article, it is with the intention of turning back to the book. 

To accomplish this, I’m splitting my months into 2 weeks for the book and 2 weeks for articles. Which weeks are allowed to vary depending on if I’m ready to turn away from what I’m working on or whether something comes up that needs to be dealt with immediately, but 2 weeks of every month WILL be for the book! It’s a simple way to prioritize the work that I want to accomplish and an effective way to make sure that work is a priority. 

So here’s to the year of the book!