#97 - Priorities and strategy mean saying no
Plus: Make yourself obsolete; Decision making; Writing more good
As you can see from this issue again being late (but less late!), here at Manager Ph.D. HQ I’m still getting into the rhythm of the new year. I hope you and your team are already firing on all cylinders.
There’s several articles this issue on decision making, priorities, and strategy. I keep coming back to this, because it’s important.
For our teams, we need priorities and a strategy. Without those, we can’t even tell if we’re succeeding, or on our way towards success.
Everyone agrees with that, but the next part gets uncomfortable. A strategy that doesn’t clearly show which perfectly good opportunities the team would say “no” to isn’t a strategy, no matter how many slide decks it appears on; it’s a motivational poster. A “priority list” which doesn’t explicitly deprioritize some opportunities, projects, clients, and activities is — by definition! — something other than a priority list.
Unfortunately, I see this quite a bit. We’ve been trained by the scarcity mindset of research to grab whatever opportunities are available, and volunteer for anything that seems like it would be high-profile. This makes it impossible for the teams to clearly articulate strengths compared to others, and build on those strengths.
But doubling down on a teams strengths is uncomfortable, because then we have to at least implicitly come clean that the team has weaknesses. That’s hard for a new leader, and even for some pretty seasoned and senior leaders.
Prioritization and strategy, when done in a way that isn’t meaningless, is scary. Unfortunately, prioritization, strategy, and decision making is the core responsibility of managers and leaders. Every decision for something is a decision against something else. Every high priority area explicitly deprioritizes all other possible areas. A strategy necessarily implies a long list of paths not taken. If your priorities and strategies aren’t choices that could be wrong, they aren’t priorities or strategies at all.
With that, on to the roundup!
How to Write a Strategy Statement Your Team Will Actually Remember - Michael Porter, Nobl Academy
Saying “no” - Mike McQuaid
Porter’s article highlights an idea that’s come up a few times in the roundup - a very clear way to write out priorities or strategy is to contrast two things, both positive, and explicitly say that your strategy values one over the other. It’s too easy to write out “motherhood and apple pie” strategies: “we value moving fast and solid code”. But those statements are fluff that don’t mean anything; you might as well be announcing that water is wet. No one disagrees that those are good things with value. Hard decisions come when good things are in conflict. When writing a new chunk of solid code will require moving slowly, which one wins? Those choices are your priorities, the outlines of your strategy.
And once those choices are made, you have to start saying no to things that go against those choices. Last January (#56, #57, #58) we had a series on stopping doing things; the first step is saying “no”.
McQuaid talks about saying “no” as “frontloading disappointment”, and maybe surprisingly as a way of building and maintaining trust. He also talks about Brené Brown’s BRAVING framework for trust (Boundaries, Reliability, Accountability, Vault, Integrity, Nonjudgement, Generosity). He writes that having a clear and explicit “API”, where it’s clear that if you say yes to something it’s going to get done, and that you say no early so they can move on, builds trust long term in exchange for a small bit of friction in the short term.
Make Yourself Obsolete: Your Team Will Thank You - Nathan Broslawsky
Porter’s article above had a simple measure of success for strategy statements - in your absence, would the team be able to make the decisions you would have made based on the stated strategy?
Broslawsky’s article continues on that theme and expands it. A good leader and manager is continually growing their team members, giving them broader responsibilities, and that means giving up some of your tasks. This means coaching rather than directly problem-solving, it means giving team members opportunities to take on high-visibility efforts, and making your old job description obsolete. That frees you, too, to take on other responsibilities.
Dagdeviren talks about the decision-making pendulum, the spectrum of decision-making processes ranging from authority (“Because I said so”), through advice and consent, to consensus decision making (“So say we all”). The processes at the extremes aren’t great for either the teams or the decisions that likely result (I don’t agree with everything Manager-Tools says, but I think they’re 100% right about consensus - consensus is a desirable outcome of a decision-making process, but it is a bad choice for a decision-making process). Within the middle, the important thing is that the decision-making process is explicit, input is gathered and seen to be taken seriously, and decisions are communicated clearly.
That input gathering and discussion-facilitation phase before and after a decision made takes some practice. Keating gives us (from the point of view of an inveterate introvert!) an overview of facilitating discussions, which can be especially tricky in the cross-disciplinary world we work in, so that the full range of ideas and information becomes available and shared.
And Shellhas gives us a bit of breathing room when it comes to decision making. The “best” decision is unknowable beforehand, when you actually need the decision; even in retrospect, determining whether it was best available is usually still impossible. It’s not a power given to we mere mortals to watch all possible timelines unfold.
But there’s often one or more nearly-tied, “good enough” decisions available. Unless a given decision has huge ramifications — which does happen, but isn’t the common case — quickly making a good-enough decision in some consistent and transparent way (maybe, say, given some underlying strategy and priorities!) is probably better for you and the team than agonizing over trying to optimize over the unknowable.
Managing Your Own Career
Becoming a Better Writer - Gergely Orosz
Work for others is getting more and more remote and asynchronous. It’s always been a bit that way for us, with large multi-institutional collaborations a routine part of work. Whether it’s a new or ongoing challenge, we do better with clearer writing. It’s a fundamental tool for clarifying our thoughts, and for communicating those thoughts to a community of work. That’s true whether it’s for a pull request, a changelog, an email to users, or an institutional strategy document. And as we grow in our responsibilities, our community of work becomes broader with more diverse expertise. Writing clearly gets more and more important.
There’s only one way to get better at something - and that’s intentional practice with real feedback. Orsoz recommends writing a lot, critical editing - by ourselves and others - and actively soliciting feedback. Orosz also recommends a couple of tools, including Hemingway Editor, which I keep coming back to. In academia we write long, rambling sentences. Twitter and Hemingway Editor help me tighten my text. As long time readers will know, it’s a continuing struggle.
Middle Managers: The Forgotten Heroes of Innovation - Ben M. Bensaou, INSEAD Knowledge
Something to remember as we rise in our careers: middle management has an undeserved poor reputation. It’s glue work, which is largely unsung and hard to even understand the value of from the outside. But middle management is where much of the cross-discipline collaboration across a large organization happens. ICs and front-line managers are typically too focussed on their individual functions, and the view from the executive suite is typically too high-level to see fine-grained opportunities to work together. Large companies like Bayer rely heavily on middle-managers to find novel ways to collaborate across the organization, as Bensaou describes.
iOS shortcuts for disabling twitter (or other time-wasting apps) before a certain time or unless you’ve done a certain amount of something else.
A key to being a good decision maker is having a good sense of the likely accuracy of your assumptions. How confident are you in your answers to true/false questions?
Like cryptography or linear algebra libraries, licenses and other legal documents are not a roll-your-own kind of deal. However one might feel about it, there are real, legally sound “open source for non-commercial purpose” licenses out there - don’t try to cobble together a dual-license MIT, but not for commercial use situation, it doesn’t work.
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 research computing team,