#146 - Structural Problems Don't Yield to Local Solutions
Plus: Flexible work arrangement survey; Talking after mass shooting; Write SOPs; Minimize WIP
I focus a lot in this newsletter about working with our teams through one-on-ones, feedback, and delegation; and communicating with other parts of our organizations with peer one-on-ones, peer feedback.
These are key communications techniques that in the research world we never really learned. But they’re essential to getting things done, helping team members grow, and to working towards a common goal. They are the basic toolkit that we need but nobody gave us for starting to manage teams.
Thanks for reading Manager, Ph.D.! Subscribe for free to receive new posts and support my work.
But they aren’t magic, and don’t solve every problem. I often talk with managers who are stuck on an organizational problem. Often - even most of the time - it really is a communications problem and be fixed with more and better communications. But sometimes there’s an underlying structural issue that won’t go away even if individuals in the organization are doing their best to work together.
But as a rule, we can’t diagnose the structural problem without trying the communications route first. Problems that appear similar can have very different causes:
Long-running tension and misalignment between two teams (data science and data engineering, say) may just be issues of miscommunication and not understanding each other’s needs, or they may come from deep routed and incompatible incentives the two teams face.
An intransigent peer our team has to work with could simply be reacting to past history with your predecessor, or there might be a personality clash, or there might be fundamental differences between what the two parts of your organization are trying to accomplish, differences that are causing real damage to company goals.
Our team being chronically underfunded while having unreasonable demands made of us might be by one key decisionmaker simply misunderstanding how your team works. Or the issue may be a reflection of one part of the organization desperately needing our work while the part that directs our funding does not see any real value to our team’s contributions.
How can you tell that you’re dealing with a structural problem, and not something that can be addressed by the usual managerial or peer approaches like one-on-one discussions and giving feedback?
Now, better communication is always the starting point. You can’t tell right away whether the problem is a misunderstanding or easily corrected. In those cases, peer one-on-ones and peer feedback will help. And even when you’re pretty sure you’re dealing with a structural issue, having one-on-one discussions with the key players and expressing the problems it’s causing will help clarify the nature and scope of the problem, why it’s there, and the language that others are using to describe the situation.
Once you’ve started having those conversations, there’s a few different ways a problem can manifest itself to be structural:
The problem doesn’t change - if even after several conversations, nothing happens, then there may be a bigger underlying issue.
The problem keeps reappearing in the same place - after an initial set of conversations, things get better for a while. But a couple of months later, there’s backsliding. Now you’re back where you started, fighting the same problem.
The problem keeps appearing in other places - you come to an agreement with a peer in one piece of the organization, and then as your work expands in scope, you start having the same problem with a peer in a different part of the organization.
When there really is a structural issue, there’s a few things that are absolutely key to recognize.
First, it’s not your fault. That may seem silly to say, but I assure you it isn’t. I have seen so many managers from the research world turning themselves inside out blaming themselves for and trying to fix problems existed before they got there, and that might well outlast them. We’re high achievers, and we succeeded in the research world because we identified problems and solved them. But that won’t always work. You didn’t cause this problem, and you might not be able to fix it.
Second, if the problem is to be solved, it has to be approached head-on. Misaligned incentives or toxic sub-organizations or fractured leadership aren’t something that can be incrementally worked on at the margins. How to approach solving it will depend on the organization and the problem — it will almost always involve building up a like-minded set of allies — but while this work will take time, it’s not something that yields to tweaks.
Third, not solving the problem is an option. Sometimes the reasonable choice is to find such workarounds as you can, and help your team do the best work they can under the circumstances. Another reasonable choice can be to leave.
If you are going to wrestle with organizational change, the resource I like most for this is a recent book:
Hack Your Bureaucracy, a book by Nitze and Sinai, for (slowly) making significant long-term change in large organizations
Are there problems you’re wrestling with that you think might be structural? Or something that appeared insurmountable that yielded to a few conversations with a key peer? I’d love to hear about it or be a sounding board - hit reply, email me at firstname.lastname@example.org, or even set up a quick call with me.
With that, on to the roundup!
Q1 2023 Flex Report - Scoop
At this point a lot of teams have settled into a relatively stable set of working conditions. It’s interesting to compare against organizations broadly.
Scoop (a company that sells software to hybrid-working teams for signing in to come in on certain days) ran a survey of US companies to give an overview of what “hybrid” is turning out in practice to mean.
A lot of the organizations that require full time on-site are either very large or those whose work is inherently on-site (e.g. hospitality, manufacturing)
A bare majority have some degree of flexibility
… the largest chunk of which (46% of those that have flexibility) have more or less maximal flexibility - it’s fully the employee’s choice when/if to come in
Other popular choices, in order of frequency: a minimum number of days per week (2 or 3, typically), fully remote(no office at all), followed by specific days per week (typically mid-week)
My impression is that most of our teams have settled into either having specific in-person team days or being fully flexible; does that mesh with your experience? What has your team chosen, and why? Has anyone completely given up their office space? I’d love to hear - just hit reply or email me at email@example.com .
The Remote Work Differences No One Talks About - Marissa Goldberg
Goldberg makes some points about the key differences with remote work. They’re points that I think most of us have kind of figured out, but I haven’t seen them expressed so concisely before; this is a nice formulation.
The big differences, Goldberg writes, are about
Accountability (between the team member and the manager and/or other stakeholders)
Judgement (of the team members)
Autonomy (of the team members)
Remote work necessarily increases the autonomy of the team member, and that means the bar for judgement goes up (theteam member has to have a more discerning take into what matters, and how to do things) as does the bar for accountability in how team members are held accountable.
In our line of work, in the world of research, we’ve typically granted lots of autonomy and required fairly good judgement(at least about the content of the work, if not the process). Where managers I talk to typically struggle somewhat is on accountability topics (and, maybe, hiring for judgement without requiring a Ph.D.).
Is that consistent with your experience as your team went remote? Anything you’d add or emphasize?
Template for Efficient One-On-One Meetings - Philipp Hauer
Hauer has a model for structuring one-on-ones and keeping notes, while still making it principally the team member’s meeting. Rather than purely text-based, he uses a shared Miro board with “sticky notes” with the following section:
What’s going well
What’s not going so well
Feedback (both directions)
How is progress towards goals
What can the manager do
Meeting minutes, with actions/todos.
I have my own text-based template that I don’t share with the team member, but the key is to find something that works for you and your team and use it consistently. Hauer’s approach seems like it could work very well for many teams. The one thing I’d add is to leave space for discussion for things not written on a sticky note - team members may well have things they’d prefer to not have so visibly in writing and easily sharable.
How to Be an Ally to Colleagues After Violence Against Their Community - Melanie Prengler et al, HBR
The number of mega-threats like mass shooting continue to rise, and these events a make members of the targeted groups feel less safe even if they’re nowhere near where the event happened. Indeed, that’s partly their purpose.
Raising the topic can feel very sensitive and high-risk if (like me) you aren’t a member of a group that faces these kinds of threats. Prengler et al try to change this by suggesting small concrete things you can do:
Educate yourself about the issues, attend community events, etc., while keeping in mind the limits of your own personal experience
Consistently share with colleagues who face bias that they are valued
Mega-threats affect people well outside of the location where it happened
Don’t pretend nothing’s happened
Ask questions like “I’ve been thinking of you in light of what’s happened - how are you doing today?”
Ask what concrete things you can do to help - “What’s something I could take off your plate? How could I make this week easier for you?”
Attend community events
Project and Technical Leadership
Write standard operating procedures - Ben Cotton
We’ve talked at length about the benefits of SOPs for teams. Cotton, program manager for Fedora, adds to that by suggesting SOPs for yourself:
Successful program management is the absence of surprises. Don’t interject your own surprises by being inconsistent in how you handle routine tasks.
He suggests a simple format:
Trigger, (when the SOP kicks in), and
Procedures - the step by step
He suggests not having the “why” of the SOP in this document; I’m not sure I agree with that. Having the purpose in mind, along with constraints it was developed under, makes it much easier to see when it can or should be changed.
Fixing “Too much WIP” - Jason Yip
At some level, we all know that switching between tasks is expensive, and that it’s better to get fewer things done quickly than more things done eventually. But, as Yip points out, too much work in progress / tasks in flight / etc. happens all the time: in his estimation, typically because
Lack of strategy - not enough focus on what matters (“incoherent problem-solving”), or
Overemphasis on utilization (“make sure there’s always something to for everyone to do”).
The reality is, there’s always more to do, and only some things are important to do right now.
Yip’s possible WIP countermeasures:
Have a clear strategy
Pay attention to throughput of tasks
Explicitly limit WIP: by items per time box, or items total, or queue size of items at each stage.
Generative AI models as lossy compression algorithms, and as prose-based programming languages that favour people with humanities backgrounds.
The argument that micromanaging is better than being disengaged. I’d add that for managers like us I see under-management occurring way more often than micromanagement.
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,
Thanks for reading Manager, Ph.D.! Subscribe for free to receive new posts and support my work.