Hi!
A question came in from a reader - I’ve talked before about how to not do things, and in my recent talk I said “do whatever others ask for” isn’t a reasonable strategy. We have finite resources, and we owe it to our communities and to science to focus those resources on the highest-impact things we can be doing. But what does that actually look like when you’ve been asked to do something well out of scope? Below’s a lightly edited version of what I sent back:
It’s important to pay attention to user needs, and thank them for their requests - if nothing else it’s useful data! But we can’t fall into the trap of trying to do everything a researcher asks for (or even every thing many researchers are asking for!). People want a lot of things, and our time and resources are finite. It’s perfectly ok for people to ask us for things, and it’s perfectly ok for us to say no.
Here’s a partial list of examples where it wouldn’t make sense for a team to provide a service that’s asked for:
The request is an XY problem - people asking for X when what they really need is Y. (Consultants deal with this all the time). An example from the last newsletter is research computing and data team leads saying they want a template strategic plan when what they really mean is “A funder/stakeholder/institution has asked for some strategic documents and I don’t know what to give them”
The request is for something that would be helpful to the researcher but would pull resources away from areas where the team is having more impact
The request is for something that is close to something the team is doing now, but the team is looking to move away from that sort of work
This request is going to be a one-off or a rare request that isn’t worth the ramp-up effort to support
There are other ways to get the needed outcome, possibly involving other service providers
The request is for something that is does not support institutional/funder/stakeholder priorities
The team just doesn’t have the time/expertise/funds - doing something poorly is worse than not doing it at all
Ok, great. There’s reasons for not doing the thing. But what now? Here’s a few ways to decline providing a service:
“That’s a service we don’t offer; can you tell me more about what you’re trying to accomplish? Maybe there’s another way we can help”
“We don’t have the resources do that kind of work currently, because we’re focussed on [institutional/team priorities]”
“That’s not the sort of service we provide, but let me refer you to a group that may be able to help”
Not doing the thing ourselves doesn’t mean we can to support the request; there’s some things we can do without getting fully drawn into the team doing it themselves. A partial list includes:
Offering to coordinate with another provider to get the work done
Offering to do the literature scan and provide best practices
Offering training or consulting on how to do the work themselves
And we can at least to try to constrain the involvement if it’s something that’ll be ongoing:
Have a very tight scope, clear efficient process for it, automate it as much as possible, and deliver it as a productized service or a product, constantly iterating it to be as low-effort as possible
But beware of this last option. There’s no such thing as a one-off in a service organization. If you do the thing, one way or another it’s going to be known that this is a thing you do now.
I’ve tried to summarize that as a diagram:
What do you think - do you have other suggestions for our readers? Let me know!
Managing Teams
How to present to executives - Will Larson
Here’s how to present to decision makers like institutional leaders, funders, and advisory board members:
The foundation of communicating effectively with executives is to get a clear understanding of why you’re communicating with them in the first place. […] When you’re communicating with an executive, it’s almost always one of three things: planning, reporting on status, or resolving misalignment.
Although these are distinct activities, your goal is always to extract as much perspective from the executive as possible. Go into the meeting to understand how you can align with their priorities. You’ll come across as strategic and probably leave with enough information to adapt your existing plan to work within the executive’s newly articulated focuses or constraints.
I’d also add that in our case we have another focus area - to advocate for things we need, such as resources or support with particular stakeholders.
Either way, the advice is good - communicating as concisely and effectively as possible is a key part of the process. Larson suggests a SCQA format (I’ve seen variants of this with different letters, but the basic idea is the same):
Situation: what is the relevant context?
Complication: why is the current situation problematic?
Question: what is the core question to address?
Answer: what is your best proposed answer(s) to the posed question?
Beyond that Larson gives several suggestions, all of which are relevant in our context:
Never fight feedback. Whether it strikes you as fair or not, it’s their perception, so you’re going to have to learn to deal with it
Don’t evade responsibility or problems.
Don’t present a question without a possible answer.
Avoid academic-style presentations - this is true even when the people involved are academics. You’re not teaching them about something that will be on the exam, you’re giving them crisp status updates or jointly aligning on a plan or adovocating for a result or agreeing on next steps.
Don’t fixate on your preferred outcome.
Random
A very cool hands-on practical introduction to deep learning by the fast.ai team. (They also have a solid data ethics course).
Lego is issuing a new 70s-style Space Lego set in August. Pew pew! Zoom!
Finally, lasers have a use for us theorists and computational researchers. Ultrafast cold-brewing of coffee by picosecond-pulsed laser extraction. Which, when you think about it, is also Pew pew! Zoom!
That’s it…
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck in the coming week with your team,
Jonathan