#162 - Understand The Underlying Dynamics Before Attempting Change

Plus: Having the Hard Conversation; Managing attention budgets; Always be Handing Over.

Sep 09, 2023

Manager, Ph.D. is a newsletter and community which helps people from the world of research reach their full potential managing teams and enacting changes. We’ve already developed the advanced skills to be exceptional managers; we just need help with the basics.

If you’re new to the community, drop me a note! Some past issues from the searchable archive which you might be interested in include:

#57, “Performance Communication is Expectation Communication”
#111, “The Complete Intern Checklist"
#130, “Taking On A New Responsibility”

Plus of course the one-on-one and feedback guides.

I hope you all had a wonderful summer! Here at Manager, Ph.D.’s world headquarters, we had a nice break, but are ready to get back into the swing of things. I’ll be sending newsletter issues out every other week, at least temporarily, while I try making some other changes.

So here's a seasonal problem I've seen a few times. We have a smart, motivated person just back from summer vacation, fully energized.

They get back into the flow of work, and quickly see, yet again, some organizational problem that is weighing them down. That is weighing their team down.

“That's it!”, they say. “I am going to tackle this problem. No one else seems to care about it. I am going to push on it. It just takes a smart person with the courage to take it on. And I will surely solve it!”

Don't do this.

If we tackle organizational problems at work this way, we will burn ourselves out, and we will be ticking people off the entire time we do it.

Maybe worse for egos like ours: The people who we are ticking off through the process will see us, at best, as clueless but well-intentioned.

So, why? What's wrong?

This mental model of a problem in splendid isolation is basically never a decent model of what’s going on. In the actual reality of people systems like organizations, that's just not how things are.

Just because something is stationary does not mean it is inert. A long-lived issue in an organization is not just lying there in static equilibrium, separate from everything else going on around it. It is part of a dynamic equilibrium. It is being acted on by forces from all over the organization from all sorts of different directions. And the problem, the obstacle you are trying to overcome, has reached the place and shape it has now sits because that’s the dynamic equilibrium it has found. It may stay put. It may look quiet. But it is being held there by a web of forces acting upon it. It is where it is, and looks the way it does, for a reason.

You needn’t be discouraged by this — I very much do not mean it can’t be moved or reshaped or removed! On the contrary, it lurched into the shape and position it currently has because of people’s actions, and thus it can be moved and reshaped by other people’s actions, people like us.

But doing it effectively will take some forethought. One more person just kind of shoving on it without being aware of any of the other actors and their exertions is very unlikely to make any kind of real difference other than exhausting themselves.

Okay, so how do you wrestle with something like this? That problem, that issue, that obstacle, is being held in place by a web of forces. Those forces come from individuals within the organization who need things that way for one reason or another, or in fact might like to move it even further in the direction that you see as a problem. Forces come from processes that rely on things being they way they are now, and would have to be massively reworked if the environment they operate in changed. Forces come from external entities who, for whatever reason, interact with this part of the system, and have dragged it over in some direction or other.

Until we take a look at that web of interactions that's settled this obstacle into the place and shape it currently occupies, we’re not going to be able to make changes effectively.

So the first step in tackling these organizational obstacles, the way to adjust this thing that's in your way, your team's way, is investigation. It’s data collection. It’s finding all the people, processes, groups that interact with this obstacle, understanding why and how they're pulling it in one way or another, and learning.

Once we start mapping out this web forces, now we can start reappraising. “Hold on. Is this even something I want to fix?” Maybe the issue, when properly understood, is far too big to dedicate time to right now. We may want to pick a different battle.

Or the situation is different than you initially understood. It’s regrettable that it causes friction for the team, but things are the way they are for good reasons, and the thing we actually need to change to remove that friction is something else. (This is the Chesterton's fence scenario).

Or maybe yes, this actually, this particular thing is still what we need to change. But now we have a better understanding of the forces arrayed upon the situation. Now we can help, ally with, and assist the the other groups that are trying to pull in the direction we’d like things to go. We can help them pull harder by pulling with them, in a coordinated way. And just as importantly, we can try to help out, to reassure, to give support in other ways those individuals, processes, and groups that are pushing the other way. Help them to see that they don’t need to push so hard, that the change won’t be so bad.

Only one once we’ve got all that mapped out can we reduce the forces impeding the change we want to see, and strengthen the forces accelerating it. And we’ll be to be much more successful in moving that big obstacle.

Okay. So if things are this complicated and messy (and they are), we can’t possibly apply this level of research to every problem we see in our organization, or that our team wrestles with. How do we pick the ones that are worth investing the time and effort to really deeply understand, so you can enact change effectively? How do we make sure our efforts are efficiently going to those issues that sap our teams’ potential the most?

I really like Micheal Lloyd’s recent technique of Dysfunction Mapping;

Maarten Dalmijn

has a nice accessible writeup here.

The idea is not to tackle problems every time you see one of their symptoms, or even necessarily prioritize them in the order by which they annoy you or hamper your team.

The idea is to take the problems you’re currently seeing, and drill further down into them. We look at the problems, the underlying dysfunctions, the positive (or at least sustaining) purposes those dysfunctions serve, and what we might be able to create as an alternative to meeting those purposes.

When we start looking at systems this way, we often find that two or three issues we keep coming across have a common cause. And if we understand what that cause is, and why it is the way it is, we can more likely

Resources I like for this:

Besides the recent flurry of articles on dysfunction mapping and the links above, I strongly encourage people who want to make changes in large organizations to read Nitze & Sinai’s “Hack Your Bureaucracy” which I discussed in #135. It’s written by people who have succeeded in enacting such change, and is full of both useful advice and helpful warnings.

And now with that, on to the roundup!

Managing Individuals

Let’s Talk: How To Have The Conversation You’d Rather Avoid - Karen Hurt

Hurt encourages us to ask ourselves five questions if we’re avoiding having some hard conversation at work:

What do I want to happen because of what I say? There’s a reason you know this conversation should happen - what is your goal?
Why does this matter?
What’s presenting me from saying it? If some hangup is blocking you from having this conversation, better to wrestle with it, because it’s probably holding back others, too.
What’s at stake if I stay silent?
What’s the worst that can happen here? In reality, most of the time there’s no bad outcome here other than some hurt feelings and friction in the relationship, both of which which can be soothed over time.

The Feedback Wizard - Steamclock Software

Lara Hogan’s Feedback Equation is one of three widely used feedback models (#65), and certainly plays a role in my own recommendations of how to deliver feedback. I’m also a big fan in using AI tools to help practice (#151) skills like feedback. Here’ s a little tool that helps you cast some feedback you’ve been dragging your feet on in the form of Hogan’s Equation.

Managing Teams

Research Culture: Why every lab needs a handbook - Tender, Welland, Miller, eLife 2023

As you know, I’m a big fan of documented processes (#121) as a way to reduce stress and wheel-reinvention, and as a place to store lessons learned and so improve faster with iteration..

Even the wild and woolly world of academic research is increasingly recognizing the value of a shared repository of “how we do things here” documents, like a lab handbook. These basic lessons apply everywhere!

Project Leadership

Retrospective Prompts - Chris

Leading a retrospective — whether a routine retro at the end of a sprint or project, or an incident retrospective after something’s gone wrong — is all about asking good questions. If important questions get skipped early on in the process, it can lead the whole group down the wrong path in their conclusions.

The author shares here a number of questions on the topics of value, planning, and knowledge to consider when reviewing and learning from a project or incident.

Managing Within Organizations

Managing the attention budget - Ben Cotton, Duck Alignment Academy

In research we thought nothing of spending hours carefully reading long papers in our field that might be relevant to what we were doing, or writing extremely detailed preprints and presentations aimed squarely at fellow experts. We and our colleagues would quite naturally devote our attention to these tomes - that’s the job, after all.

Our current roles aren’t like that. Rather than a small number of Big Things we’re thinking about, we and our peers have a large number of small or modest-sized things we have to keep track of. That means that any long document, or constant stream of small documents, that won't immediately help a peer or someone senior tackle a problem they’re wresting with will get filed under “I’ll read this later”, which realistically means “I’ll probably never read this”

Cotton talks about this in the context of open source program management:

Your day fills with announcements, updates, and other communication. The person who sends each message thinks it’s important, but the recipients are drowning in “important” messages. As a program manager, your job includes helping your community manage the attention budget.

In the article, Cotton provides some suggestions for managing this budget of your colleagues attention - some of the most relevant for us are:

Separate the must-know from the good-to-know.
Batch related announcements.
Make announcements skimmable.
Say no more than you need to.
Make status updates [LJD: and other non urgent updates] visible [asynchronously].

I used to make this mistake all the time - in the interest of being transparent with team members and stakeholders, I would flood them with meeting notes, updates, plans, roadmaps…. essentially launching a continuous denial-of-service attack on their attention, and then wonder why when talking with them they didn’t know any of the material I was referring to. When I learned to instead just make material available in a common place, and judiciously and occasionally share extremely relevant and personalized updates with links to the available material, I saw a huge improvement. People read the updates (eventually, once they got used to my new more targeted approach), and learned that they could look up material when they needed it, not when I thought they should know it.

Managing Your Own Career

How to Write Amazing Handover Documents -

Benedikt Kantus

Leading in Product

I refer often to Merino’s article, “Always Be Quitting”, which I covered in #70. Maybe another way of saying that would be “Always Be Handing Over”.

Part of our job as managers is to make ourselves personally less and less necessary - to help the team become self-sustaining, to support the team members who want to take on more leadership and scope as they grow into those responsibilities, to teach and empower the team as individuals and collectively to make good decisions.

We can do that on a spectrum from routine small delegation (#154), through to practicing larger-scale handoff during our vacations (#123). Anywhere along the spectrum, having some kind of hand-off document providing context, possibly current SOPs, and what success looks like, will be useful.

Even just writing up handover documents is useful. When I wrote my handover documents in my last role I discovered many missed opportunities for delegation, and ruefully saw many places where my work wasn’t really aligned with my priorities (#101).

I’ll be recommending Kantus’ nice article on what should go into such documents now too along with Merino’s. The article covers his recommended sections in more detail:

The big picture - concise overview
Ongoing projects and developments
Roadmap and future plans
Stakeholders
Documentation
Tools & Technologies
Known issues and workarounds
Lessons Learned
More personal information about the team

Kantus writes this in the context of a software team, but it’s a great outline for what should be covered and applies much more generally.

I’ll add that when I was actually handing off to an incoming manager, I also wrote up a document covering each team member, that was basically a summary of the information I kept in the cover sheet of my one-on-one notes for each team member:

Background
Career goals
Working on now
Working on next
Gaps
Retention Risk

Keeping the cover sheet up to date as part of the quarterly goal setting practice (#60) meant that this team member document came together quite quickly.

That’s It…

And that’s it for the week! I hope it was useful; Let me know what you thought, or if you have anything you’d like to share with me about how a newsletter or community about management for people like us might be even more valuable. Just email me, leave a comment, reply to this newsletter if you get it in your inbox, or schedule a quick Manager, Ph.D. reader input call.

Have a great weekend, and best of luck in the coming week week with your team,

Jonathan