First Lessons learned as a patient PI

I am the Principal Investigator for the Opening Pathways project, which means I’m responsible for guiding the science of this work to ensure we can translate it into valuable, long-term insights. My team - and my grant officer - have learned that I’m probably the least patient PI - even though I am a patient PI. It’s an ironic play on words where I am a person living with a health conditions (e.g. a “patient”), but I’m one of those who has said #WeAreNotWaiting and looks for efficient solutions to solve the problems of today, not just focusing on the long term problems.

Play on words aside, I’m finally sitting down to write up some of my lessons learned in the first few months of being a PI. Some of these are probably not unique to being a patient in this role, and are similar to other first-time PI learnings, but in either case, I think they are worth documenting and discussing.

As a reminder, the Opening Pathways project is about a concrete body of work (data science work; gathering expertise from traditional and non-traditional perspectives to document barriers; and developing tools to help people who want to overcome those barriers to innovate and research), and also a meta-examination of the process of how we’re doing this work.

Here is some of what I’ve learned about the experience of being a PI:

1. Paperwork (ugh)

What I thought: being a PI is about leading the team and directing (and doing) the science. Reality check: “Being a PI is about doing paperwork” - (quote by John Harlow, which has stuck in my head about my biggest frustrations)

There is a lot of paperwork involved in doing research & having a grant, and it’s complicated even further by the way this grant is set up. Part of it surfaced out of a good intention that I had. I had to decide how I wanted to be funded. I could join as staff at ASU, and ASU become the grantee; or I could create my own organization and do all the admin and finance stuff, with ASU becoming a subcontract; etc. But I know it’s relatively ‘easy’ to be absorbed into an organization, and that’s typically been what people do; but I wanted to explore other options, including what it would take to remain independent. And that’s the route I chose, which meant that ASU became the grantee and I would be a subcontractor.

The benefits of this situation: ASU has staff and a lot of experience administering grants. I would get to explore the challenges that come with being independent, rather than employed by an organization while doing this work. And I wouldn’t have to do grant management/spin up an organization.

The challenges of this situation: Hoops, paperwork, and more paperwork hoops.

• When we were awarded the grant from RWJF, one stipulation was that RWJF required reviewing my contract with ASU before it could be signed. (Smart, and I’m glad they did that, as it helped protect me as an individual). I worked like crazy to make sure that my contract would get reviewed and approved by all parties (including me) by the start date of the grant. I thought that was all that needed to be done, but nope. It turns out there’s a bunch of other traditional subcontractor paperwork and processes that also had to be jumped through, and it took a long time after the grant started before I was officially completed in the ASU system.
• Why does this matter? Well, this influenced my ability to get paid. For anyone going into this situation in the future, make sure to plan to have some financial buffer (and add an extra two months beyond that for any paperwork kerfuffle). It took 4 months after the grant started to get my first check from my first invoice. Ouch.
• The second invoice was also a long time coming, even though I was in the system. Why? Well it turns out, because of one of my co-PI’s moving (more on that shortly), approvals were still going to his old email box, so despite the fact that he had signed my invoice authorizing it, it still required an e-signature, and so it got stuck in a black hole for a while. Sigh.
• Thankfully all is well now, but paperwork related to starting the grant, getting paid, etc. was the bane of my existence for the first 6+ months of the grant. This sucked up a LOT of time and energy that it shouldn’t have. Additionally, ASU’s standard subcontractor forms and processes are not designed to accommodate individuals. Much of the original contract they provided me had to be x’d out and rewritten because it only applies to companies.
• Also complicating things is that one of my two co-PI’s - and the lead PI on ASU’s paperwork with all the signing powers - switched institutions in December. This meant that we had to transfer everything over to the other co-PI in ASU, which was another set of paperwork and confusion. Thankfully, this is why we have an administrative person on our team, but it was still challenging and a lot of “who’s on first” and “where is this?” between me to her, and her to various departments across ASU to sort everything out. We also had to then add UCSD as a subcontract, and we need to resubmit a change to RWJF and… it’s all a lot of tracking and paperwork and taking time away from the actual grant work.

Summary: it’s going to be more paperwork than you expect; having an admin person at the grantee institution (ASU) and on your team is key for saving your sanity; don’t let your co-PI’s change institutions mid-grant if you can help it! ;)

2. IRB (also ugh, but don’t jump to conclusions - read more for why)

Our initial IRB submission was pretty straight forward. It only got slightly complicated by the fact that Sayali, our data science lead, is also working on her PhD in a related space and we added her dissertation work in the same IRB submission. Our actual Opening Pathways data science IRB request was straight forward - we’re using already donated, anonymized, online data from the OpenAPS and Nightscout Data Commons. But, there was a little bit of initial confusion by who would be “participants” according to that IRB submission. Technically, our data science work doesn’t have ‘participants’ - we have people from the community collaborating with us on data science and research question development (which was approved by the IRB and reviewed by our legal support provided by RWJF). But, Sayali’s dissertation technically has participants (people she will be interviewing), so it’s been an ongoing balance of confirming which project (her dissertation work, or our Opening Pathways data science work) we’re talking about when questions arise. Additionally, because I’m not at ASU, I can’t officially submit the IRB request, and there’s a little bit of telephone in terms of finding out what the status of things are and what actions are needed, if any, when questions pop up.

Additionally, because Eric had moved to UCSD, the question bubbled up about what we needed to submit to UCSD IRB. There’s been some back and forth between ASU wanting one thing and UCSD saying another. Like the paperwork ugh, it’s a little bit of a headache that’s slightly slowed down the data science work. We’ve gotten it mostly squared away between the two IRB’s now, but I’m still frustrated about the fact that it even popped up and took so much time to sort out.

Summary: try not to mix any other project in with your IRB submission; having more people from more institutions will also complicate your IRB review of project work.

3. Speed, and relative perspectives

With all of the IRB/paperwork headaches at the start and ongoing in the grant, I felt like the grant was slowed down by it all - and that was really frustrating, as I was cognizant of the fact that it was already a short (18 month) grant, and I felt like some of this was wasting precious research time and other resources. This is a continued frustration that has ebbed and flowed throughout the grant so far.

What’s funny, though, is how the perspective is very relative to where I am coming from. On the other side, our research team and grant officer were all pleased with our progress, and in fact thought we were moving ahead of schedule and faster than they all expected us to be going!

The best articulation I have of this juxtaposition of perspectives is remembering our grant officer on a monthly call a few months ago say, “whoa, slow down” during an update of our work. He also said something about feeling like he was holding on by his fingertips to the back of a truck that was barrelling down a highway (that I was driving), in terms of speed.

That made me feel a little bit better about things, in terms of exceeding expectations.

At the same time, I also remember him joking about getting off a call at the start of the grant, and another RWJF-er asking him who he had been speaking with, and after finding out it was me, saying “Wait, she isn’t done yet?” (Given that they know I want to/will move more quickly than traditionally might be done.)

That definitely stressed me out, as I already felt like we had ambitious plans for what we were going to accomplish in a (mere) 18 months, and I worried about setting the right expectations for our communities of patients as well as for RWJF in terms of what they’d get out of/learn from our work.

I think there’s a separate blog post about this in the making - talking about the different perspectives of how we each address this work, especially comparing my perspective with my team’s perspective - but a short, high level take away point here is that although we are hitting our project milestones, I would definitely suggest patient PI’s budget more time in up front for getting the grant up and running (paperwork! IRB! etc!) so as to not be disheartened by seemingly slower speed than they know they could achieve otherwise.

4. Communication is key

I’m not sure this is a lesson learned, rather than a lesson reemphasized to me at least once a week: communications matters. Communication is critical. This is key for setting up your project clearly; communicating expectations so your team is all on the same page; fixing miscommunications that pop up with virtual teams or multi-channel communications; communicating with your communities; communicating with your grant organization and officer; etc.

My team spends a lot of time talking about communication, and it has helped immensely - and especially in building team culture. I came into this project stating that I would be asking lots of questions - especially “why” questions - to seek to understand their perspective, because I know they have a lot of assumptions and expectations (based on their training/careers/ecosystem) that I don’t necessarily share, but want to learn about, as those color their work and how we work together.

In fact, some of the best scientific learnings from our project so far has come out of some of those “why” discussions. It’s also provided space for a lot of “a ha!” moments for them to also understand how I work - and why I work the way I do - to help us document what we want to share with other patients who are looking to research, innovate, and collaborate.

(And some of them are already blog posts here - if you haven’t already, read Apples, Barrels, or Barrel Makers?, Cultural Consciousness, and Honoring Agency for three great examples of discussions and ideas that came out of team meeting discussions).

So, while I thought this was about being a new PI, and about being a patient PI, I think this focus on communication, clarification, and seeking to understand has been a superpower of our research team.

Summary: don’t overlook the importance of communication. Many people think communication is external (e.g. a poster presentation of a piece of work). Strong internal communication between team members; with your grant officer; and with other people connected to your work is essential.

5. There are many other skills required - don’t let what you don’t have overrule what you do have

I had a lot of imposter syndrome coming into this project. And it’s better for me to acknowledge it up front and talk about it, rather than let it paralyze me. Some of my frequent thoughts include “I don’t have a PhD! I am not a traditional researcher. I don’t know everything.” The negative thoughts, or the thoughts framing what I don’t know/experiences I don’t have, have been the loudest thoughts at the beginning of this project.

But recently, I’ve had a mental shift - especially after reflecting on the beginning of this work and where we are today as we head into the second half of the project - to recognize all the skills and experiences that I do have that have played a beneficial role in this work.

I’m going to talk about some of them below, but I want any other patients thinking about this to read with this giant caveat: I’m not saying you need all of these skills (or any other list of imagined skills/experiences you wish you had/have). But what I’ve learned is that it’s important to recognize the ones that are helpful to you; and if you can’t gain them (time/resource constraints, etc.), leverage your team and delegate or ask for help to make sure that some of these areas are covered, or to help you learn and grow in these areas.

A. Vision + delegation

Vision is the most important thing to have, and the ability to assess a new opportunity or facet of work and say, “does this fit with our vision?” and say ‘no’ to the opportunity/work if not.

It’s hard, especially as a patient, to do this. And your perspective on this may change over time with your goals, but I think even patients who are getting started on a project should acknowledge their vision and use that to assess whether things ‘fit’ or not. Just because work can be done, doesn’t mean that it should be done - or that you should be doing it.

Delegation is also key here. It’s important to learn about the skills and strengths of your team members, and to learn how and when to delegate to them. I’m still working on learning this, but just because I can do a piece of work (and think it should be done as part of our vision of work) doesn’t mean I should be doing it. (I’m especially working on this right now with the data science work for our project, where it is more important for me to coach and mentor those working on our data science team than to cave in to my urge to just go off and write more scripts to process the data. Instead, I’m trying to focus on training & supporting more people on the team, so they can help take on more projects, thus scaling more efficiently than I could as an individual.)

Because I had a fairly strong vision of this work, I think I’ve sometimes surprised my team members with strong opinions about proposals of what we should be doing. And having this strong vision has helped when I’m feeling imposter syndrome to make the decisions necessary to steer our work in the right direction. (And the other thing that’s played a role here has also been Eric, Erik, and John in particular being *amazingly explicit about stepping back and saying “your call, you are the PI” or pointing out what a PI might traditionally do, and allowing me to factor that in but make the call based on what I think is actually right, not just bowing to tradition.*)

B. Communication

I mentioned before: communication is critical. Because I come from a communications background, and probably also because I have this personality of wanting to communicate, it’s been a big focus of our work. This has included writing up blog posts about our work; presenting at conferences; keeping communication strong within our remote team; and more.

Things that have helped further communication within our team:

• Using Google Hangouts for video chats, so we can see each other during team calls. Facial expressions, and hand gestures, make a big difference. It also helps for hard conversations when you’re being emotionally vulnerable about something. Further bonus: cats on conference calls are awesome!
• Using Google Docs for notes for each type of work. We have a long running Google Doc that is agenda + minutes for every team call; we have separate documents for data science work, etc. That transparency, available to the entire team, is beneficial for emphasizing the transparent nature of our work and also helps if someone is unable to join a call, or we need to go back and reflect on something that happened previously.

C. Comfortable working with remote teams

If I wasn’t already comfortable working remotely, this would have been pretty hard to get used to while also bringing together a new team for a new type of work. It’s a lot of work to build a team culture, and to do the work we’re doing. It’s hard when you can’t just walk down the hall to chat. It’s hard when you don’t have the water cooler experience.

One of the things I did was schedule an in-person meeting to help kickoff our team work (and this was budgeted into our budget from the get-go). This was incredibly beneficial to build a baseline of understanding and start developing our team culture. (It also really helped in terms of building some knowledge of diabetes data for data science work - there were some great ad-hoc whiteboard sessions that you just can’t replicate online.) That made it easier to connect and engage virtually for the rest of our work. We also took the opportunity to do an in-person team meeting again this spring when many of us were scheduled to be in the same city for a conference. I didn’t have that many in-person team meetings budgeted for originally, but we found a way to make it work, and for future, I would add more in-person team meetings to the budget even though our work is primarily virtual.

I did pull PI about one thing, though: time zones. Time zones are a pain for scheduling meetings, and especially so when your team was originally all in one place but then splits to three/four different time zones (Pacific, Phoenix which does it’s own funky thing away from my Pacific time zone sometimes, and Eastern). Very early on, I decided we would anchor on “Dana time” (since my home airport is Seattle) and use that as the reference for time zones, and let everyone do their own conversion from there. That cut down on the mental gymnastics required to identify and communicate ideal meeting times, quite a bit!

Related to time zones - I prefer to start calls at/after 10am Pacific. But we have an Eastern time zone team member, and respecting the end of his work day means our window for calls is usually 10-2, Dana time. I will cave and do earlier meetings if we have no other options that week for the full team, but it’s helpful to be aware of your team’s time zone/family schedules in general to have a general guideline for when good regular times are for meetings, and also in terms of understanding turnaround times. If, like today, I finish this blog post by 2pm my time and send it off, I’m not getting a same-day response from John. But I know he’s likely to look at it and respond by the time I start working the next day, unless I let him know it’s coming in at the end of his day and it’s an urgent need.

Summary: Managing expectations related to time zones - and work commitment in general, because this is not the only project that everyone on our team is working on - is really helpful for limiting frustration about back and forths between team members. Also, budget at least one more in-person meeting than you think you need!

D. Experience managing teams or projects

As I mentioned earlier, I think there’s a lot of similarities of learning curves for patient-as-PI and first-time-PI’s. Similarly, I see a lot of parallels for being a PI (leading a team doing scientific work) and leading other types of teams.

Thankfully, in my old day job career (healthcare communications), I had several experiences managing and leading teams. I’m emphasizing managing (paperwork etc.) separate from leading (team development & support of individuals on the team). I’m by no means perfect, but I think it definitely helped to have those experiences before taking on this work.

I underestimated the amount of time I spend on our team management for this work, compared to what I thought it would take. Granted, again, I have some time saved by already learning some lessons related to leading a team, and again, for working remotely/virtually, but I wanted to explicitly call that out for anyone taking on a patient PI role if they hadn’t had those experiences. I would explicitly budget some of the time you have allotted for team management and facilitation, instead of just ‘doing the work’ of the grant.

For me, we had budgeted out of our grant funding a salary that roughly equates to 40% of my time. There’s enough there that I can thankfully shift the type of work I’m doing around, but during some time frames where I needed to do more of the data science work, or the month of June when I did a lot of communication-related work for presenting our work at a scientific conference, I could have benefitted from having more budgeted there. Now - a budget of time/funding is never going to be perfect, and you should always have a % of buffer for contingencies, etc. I had budget contingencies allotted, but I probably would have added (and will add, for any future projects with grants) some contingency time factored in to account for the paperwork/team management aspects of the project that I wasn’t fully cognizant of in designing this project.)

Is managing an official team the only way to get these useful experiences, or to learn some of these skills? Nope. In fact, some of my unofficial leadership (community moderation of online communities, helping train people to do pull requests of online documentation in the diabetes community, etc.) has gained me additional useful skills that also play a large role in being PI on this project. There’s a lot of transferable skills from all kinds of experiences that patients can leverage when leading work. So don’t overlook ‘soft’ skills and experiences of informally managing projects, pieces of work, or communities online!

Summary: Having led teams (officially in organizations) and projects (informally, online) has given me some useful skills that helped ease the number of things I had to learn when transitioning to being PI.

Conclusion of this post (but not of the learning experiences)

I’m carefully emphasizing this is the conclusion of this post for now because I am still learning about being a PI and doing this kind of work, and expect to keep learning beyond the end of this project! I expect that I will write additional posts in the future about more lessons learned from these experiences.

I hope this is helpful for fellow patients who are thinking about grant funding, taking on PI roles, or otherwise taking on leadership in their communities or projects. I don’t want this to be overwhelming (it might be to read this all at once!), but I do think there is a lot more to be unpacked under what it takes to be a PI; what has been helpful/not; and to recognize both where I’m learning new things and also where I’ve been able to leverage past experiences/skills.

With that being said - please also feel free to comment here or on Twitter, as always, if you have questions or comments about this work & the meta-experience of being an impatient, patient PI!