From the Archives #139 - Taking on a New Responsibility
Plus: Setting direction; introverted leaders; Software processes and variants
Hi all - I hope you’re enjoying the summer!
This is my last summer issue from the archives (this is from September 2022) - two weeks from now we’ll go back to normal posting. Let me know what you think, and enjoy!
Say you have taken on an existing responsibility. It might be being promoted to manager, it might be a new job, it might being put in charge of some effort that already has some history. (And in our institutions, every effort already has some history. There are no completely de novo efforts in our line of work). What should you do?
It’s mathematically possible, of course, that someone in our roles taking on a new responsibility has clear guidance from their boss, and is receiving routine and helpful support and coaching on on their efforts, so that they feel like they’re in good hands. Yes, yes, stop laughing, I said it was possible.
For the rest of us, figuring things out on our own, there are two common failure modes: freezing, or doing too much too soon. It’s important to fight both of those instincts.
My guidance in these situations is to keep things moving steadily, gather all the data you can, report back to everyone, and only then - likely three or so months later - start building a library of small quick wins that, hopefully, solve multiple problems.
The big picture here, the guide star to follow, is that someone taking on a new work responsibility for things that will affect people has two and only two initial tasks. Task one is to learn what the heck is going on; task two is to build trust and respect with the people their efforts will effect. You can’t execute on your responsibilities unless you see them and the consequences of any actions clearly; and you can’t get anything significant and lasting done without the trust and at least grudging support of most of those you’ll be affecting. Everything else is tied for a dim and distant third.
First: Do no harm
So, congratulations! You’ve been dropped into some pre-existing human system, and are charged with executing on some new responsibilities.
Human systems are complex. Changes to complex systems always have multiple consequences. And the thing about complex systems is that unintended consequences are basically always bad. Until you know enough about the humans you’re dealing with and the related systems they’re part of, not only can you not guess ahead of time what the consequences of any changes will be, you won’t even know how to detect them when they do happen.
So your first job, while you’re learning things and building trust, is to keep the lights on, keep expected activities happening, and not make any changes yet. Learn what the steady state looks like first.
You might think (as I certainly did in an earlier role) that if you already have experience with this effort or this team — say you’ve just been promoted from IC to leadership — that you have the background knowledge necessary to skip this and the next step. I was, and you would be, very much mistaken. Indeed, I did and you would know just enough to be dangerous. There’s still a bunch of important context you’d be missing. Steady on.
There may be something that is obviously, dangerously on fire and leaving it alone for a while isn’t an option. My guidance here will be painful to hear for those of us with expertise and a desire to fix things. And yet. Unless you’ve been directed otherwise, do the smallest, most self-contained, most hacky thing that can possibly be done to keep the flames down to a containable smoulder for a while, make a note of what’s happening, and move on. You don’t know enough to fix this properly yet. You just don’t. Give the people around you some credit. If the fix was so obvious and easily done that someone just walking in could fix it, the thing wouldn’t be on fire right now.
Second: Listen, Listen, Listen
Your second job is to gather all the data you possibly can.
(I mean people data. We’re all experts here of one sort or another, so I’m not going to advise you to learn the relevant domain knowledge for this responsibility - we take that as a given, and frankly have probably already started doing that because we enjoy that part. I’m focussing on the messier, trickier, people stuff.)
If you’re part of a group of people, and there’s no practice of one-on-ones yet, start one-on-ones.
And start having one on one conversations with others. Create a list of key stakeholders, of teams you’ll be interacting with, of people your actions will affect, of people whose actions will affect you. Start working your way down that list, having one-on-one conversations with them.
In both cases, ask them questions about how the responsibility you’re now charged with has gone in the past, what’s important about it to them, what they worry about, what they think is under control, what kinds of interactions they’ve found valuable - keep them talking and take copious notes. Write down exact quotes of anything they say that illustrates a point particularly well.
Use all your active listening skills here - listen more, speak less; paraphrase what they’ve said for validation and clarification; ask followup questions; sympathize; don’t offer your own thoughts.
The task here is to gather all the data you possibly can. Fight against the temptation to interpret it right away – you can’t interpret a individual noisy data points. The work here is to gather lots of data points so that trend lines later emerge.
Remember that if a person says they experience a problem, they are absolutely correct about their experience. But anything else they offer (an assessment of the problem’s priority broadly for the community, a diagnosis of the underlying issue, or a proposal for a solution) is just their own interpretation filtered through their own perspective and likely lacks other important context, context you’re still collecting. If a number of people experience a problem in the same general area, there is obviously a very real problem somewhere around there that will eventually bear thinking about, but it might not be what they think it is. Collect the data impassively, gather it without interpreting it.
Third: Report Back
Report-back will be in a few different phases.
For external people you’re not talking weekly with, within a day or at most two send them a thank-you. Include with the thank you distilled and coherent notes from your meeting, ask them for feedback to correct or expand on anything in the notes, and invite them to follow up by email or another meeting if there’s anything else they’d like to cover.
This follow-up is absolutely entry-level professionalism stuff, but I’m continuously surprised by how uncommon a practice it is in our profession. Yes, it takes work. In my experience, distilling notes from a meeting into something other people could read and learn from takes roughly as long as the meeting did. But remember, the goals here are to learn what’s going on, and build trust. Sending lucid notes after your meeting and requesting feedback means organizing what you learned while the meeting is still fresh in mind, getting that validated by the person you learned it from, and communicating to them both that you took what they said seriously and that you follow through on conversations with them. That is what makes the meeting worthwhile (for both of you) in the first place!
If you’re working with a team, periodically report back distilled, anonymized versions of what you’re hearing from stakeholders. Making use of the direct quotes you jotted down is an extremely effective way of helping the stakeholders communicate a point. Once you’ve heard from all the team members, you can also summarize what you’ve heard from the team members back in an anonymized way. (Be careful with direct quotes in that context - people might recognize each other’s words). Don’t let the team react too strongly (positively or negatively) to what you’re reporting back, and don’t start making changes yet; the context here is that this is what people are saying, stuff to be aware of, and things to think about. Make it clear that this is part of an ongoing process, and as it winds up you’ll collectively decide what’s next.
When you’ve heard from all of the external voices, distill everything you’ve heard — still without interpretation or next steps — into an easy to read document. A slide deck works well for many, but it could be anything. As before, make generous use of (anonymized) direct quotes. Run it by your team if appropriate, and then send it individually out to everyone external you’ve spoken to, and then offer to schedule a time to walk through it with them and collect their feedback.
This has likely taken months. Ninety calendar days is a commonly cited length of time, enough to learn the lay of the land, and for people to start thinking “one of us” rather than “that new one who just started”. You now have a firm foundation to build from.
Fourth: Start building small multi-purpose changes
The first three steps are all about learning what’s going on and building trust. You build trust with people by listening to what they have to say, being seen to take it seriously, and following through on things. Those are all things you’ve started doing. Now you have enough background knowledge and trust built up to start getting some things done.
In the distillation of data you’ve done, some patterns have begun to emerge, and some likely priority areas taking shape. You’re already starting to see where systems interact, which people are affected by what area, and where the effects of small changes would have ripple effects.
What the next activities will look like will depend a lot on the nature of your new responsibilities. But in all cases, the goal is to identify some small wins. You’re still learning how systems interact, and still learning how to work with new people, so it’s baby steps first.
Find small changes that could be made that address more than one problem area, or more than one opportunity. You don’t want to start by making surface-level tweaks. Also, remember the law of unintended consequences! It’s likely that any change will cause its own downstream issues, and you don’t want to just shuffle problems from one area to the other. The goal is small changes that have noticeable effects on a few issues that a number of people have suggested.
Validate your proposed priority and approach with (at least) the affected people, and start making changes. Keep talking to people, and pay very close attention to how things are going. Once one change has been successfully made, and the consequences understood, report that around and begin with the second. Keep your lines of communication open, and start building lines of communication directly between stakeholders. Start building momentum.
Making things happen with a new responsibility is hard, but the key is to start with the foundation of knowledge and trust from other people. Put that work in, steadily and consistently, and big things slowly become possible. We too often overestimate what we can do in a week and underestimate what we can do in a year.
Some resources I really like for this topic (and if you’re familiar with them you will have seen their influence on what I’ve written above) include:
The First 90 Days - Michael D. Watkins; mainly aimed at senior leadership, but much of the discussion here applies
90 Day New Job Plan Podcast Series - Manager-Tools; I particularly like the bits about taking on the role of “the voice of the customer” (and yes, you have customers)
Hack Your Bureaucracy - Marina Nitze and Nick Sinai; just working my way through this now, but I think you’ll hear more about this book from me. It’s a very practical guide to getting change done in complex human systems. (And our human systems are more complex than most.)
I’d like to emphasize that even if you’ve had a responsibility for a while, it’s never really a bad time to go through this process. You can always find some excuse — a new academic or financial year, an upcoming project kickoff or wind-down, a new hire or departure — to collect a bunch of data, have conversations with stakeholders, and start making some new plans and changes.
Any thoughts? Anything I’ve missed that you’d add? Let me know - just hit reply or email me at jonathan@managerphd.com.
And with that, on to the roundup!
Managing Teams
Setting Direction: Create a Strategy - Chase Seibert
Siebert describes the basics of strategy, using 1997 Apple as an example and leaning heavily on Richard Rumelt’s “Good Strategy Bad Strategy” book:
He also selects a quote that is both correct and weirdly appreciated in our line of work:
Good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests. Strategy is at least as much about what an organization does not do as it is about what it does.
Everything is tradeoffs. Any strategy is necessarily some form of specialization along some dimension. “We do everything” is not, and never can be, a strategy.
Rumelt’s two books are really quite thought provoking. (They’re more filled with anecdotes than I care for, but others find that an extremely helpful part of the book, so.) If you want to read a book on business strategy, one of his are the ones I’d recommend. But our context, where we (unlike Apple) can’t just pivot to something completely different, is a more constrained than business strategy writing generally allows for. La Piana’s book, “The Nonprofit Strategy Revolution,” is starting to grow on me for an RCD team situation.
The Coach and the Fixer - Michael Lopp
Lopp talks here about the tension between being the coach/listener, and being the fixer/one who takes action. One or the other of those is likely more comfortable for us, depending on the situation. The problem is, we as managers and leaders need to be able to call upon both as needed.
Why are process gates the hellish spawn of evil you should avoid at all costs? - Jade Rubick
When something fails, the perfectly understandable first reaction is to impose more oversight on whatever that process was, and to require some sort of quality control between the creation of the next thing and its release.
This approach is seductive, because from a management or lead point of view it feels like we’re Doing Something. And, you know, there are some times when these kinds of gates are needed. If you’re going to be updating medical devices, you’d best make absolutely sure the new versions work properly.
But as Rubick points out, these stage gates multiply, slow everything down, erode the sense of ownership of team members (since it’s pretty clear they’re not trusted to do their job). Our jobs as managers and leaders isn’t strict oversight, it’s to build a team and processes by which good outcomes happen without our intervention.
As in Silverio’s article in #134 says, the key is to make sure any bit of process function has a clear purpose, and to constantly review them make sure they’re needed and that they’re the best way of achieving their aims.
Managing Your Own Career
Being an Introverted Leader - Matheus Tait, Thoughtworks
We’ve talked about this on and off since way back in #4, but it’s worth repeating. As a manager or lead at various times you’ll need to talk and to listen, to be assertive and to let others take the lead, to be detail-oriented and to see the big picture, to be people focussed and to be task focussed. There is no one whose default behaviours covers all of what’s needed, because different situations call for different and even conflicting behaviours.
Here Tait talks about his own struggle with being an introverted leader, and his first three suggestions could be just as easily applied to any personality trait:
It is not a problem to be solved
Capitalize on your strengths
Recharge moments
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 couple of weeks,
Jonathan