#116 - Strategy, Strategic Plans, and You
Plus: When Feedback doesn't Land; Cash-strapped hiring; Technical team effectiveness
Hi, all!
I want to write a little bit more in the coming year about strategy for leaders who come from a research background: setting priorities; deciding what and what not to do; and deciding what success looks like. It’s an important topic - and yet as with so many things in our line of work, no one teaches us how to do it.
A strategy, ultimately, is a means to solving a problem. You have a problem: say how to reach sustainability, or how hire and keep good team members, or how to position your team against a number of other local and remote teams. A strategy is a choice, a decision, about how you will solve that problem, given the existing situation and the tools at your disposal. Remember the story of how Pauli dismissed a paper as “not even wrong”? A good strategy, like a good theory, must possibly be wrong. If it couldn’t be wrong, it isn’t a strategy. If someone else couldn’t defensibly make a different choice, it isn’t a strategy. If a choice doesn’t address a well-defined problem, it’s not a strategy. Aspirations to “excellence” or “high customer satisfaction” and the like aren’t strategies. (The canonical book to cite here is Good Strategy, Bad Strategy. I’ll warn you though, especially in academia, getting into this is like learning to recognize bad kerning. The badly done stuff is everywhere, and seeing it constantly gets really annoying).
Strategic Plans are a poorly named genre of documents. (Naming things is hard). It isn’t a plan - it doesn’t (and shouldn’t) say “we’ll do X, then Y, then Z”. It also isn’t a strategy, though it should implicitly be the documented outcome of deciding on one or more strategies.
Let’s say you woke up one morning and found yourself in charge of an organization that faced new opportunities and challenges. A good strategic plan is something you could use to guide you away from some otherwise plausible choices and towards others. It’s a document which gives clarity about how big picture decisions will be guided - about the principles around which those choices will be assessed. It gives stakeholders clarity about what the organization is for, what it will be doing even when challenges arise, and if it can help them meet their goals.
Any document providing such clarity to leadership and stakeholders about what the organization will do when faced with opportunities and challenges is a perfectly fine Strategic Plan. Sometimes smaller versions of the document for smaller or sub-organizations is called a Strategic Framework. That’s is a better name, because it is a framework - or at least guardrails - for making strategic decisions (for the leadership, but also for stakeholders).
Plan or Framework, there’s no fixed structure for such documents. The most common approach is to have a section describing what the organization is for (with enough clarity that it’s easy to understand what it’s not for), the broad classes of activities it will undertake (often with some prioritization), and how it will measure whether it is accomplishing its purpose. But the essence of the document is the shared understanding of what the organization is and how it will be guided, not the section headings. For a modest-sized team, a well-written Strategic Framework type document could be a page or less in length, and would likely be called something less pretentious, but it would serve as one just fine.
Bad documents, on the other hand, cite lofty goals, too big to be achievable and too fuzzily defined for anyone to know for sure if they had been achieved anyway. They list grab-bags of individually worthy but collectively incoherent activities. The measures for success are just counts of things they do and not measures of what they’re trying to achieve by doing those things. They leave stakeholders uncertain as to what’s in and out of scope if new opportunities arise, or what the true priorities are if activities have to be scaled back. They leave leadership with no concrete guideposts to inform challenging decisions, and stakeholders no hint as to how those decisions will be made.
The problem with Strategic Plans/Frameworks, and why I think there’s so many crummy ones, is that the good ones are unremarkable and boring. They are the documentation of clear decisions made about what the organization is for and how it will measure its success. Read after the fact, you’d be forgiven for mostly forgetting having ever laid eyes on it.
But, that’s huge. Getting an organization, a team, and stakeholders aligned to the point that they can clearly lay out what the organization is for and how it will measure whether it’s doing a good job is an absolutely foundational success.
Our job, as leaders, is to reduce uncertainty (#26). We are life-sized Maxwell’s Daemons, manually reducing entropy within and at the boundaries of our organization, so our teams can help our stakeholders in the way only they can. Discussing the purpose of an organization or team with stakeholders, and building enough consensus to agree on a relatively quotidian document, while having that document as an artifact to continue basing decisions around for the next few years, is a real accomplishment.
And it’s doable! Like most of management, the successful outcome is boring and mostly invisible, but it’s doable. Getting to the point of having that document is almost never boring, mind you. The discussions can be quite… vigorous. But it is absolutely doable.
Any kind of strategy, and any kind of strategic planning, is ultimately collaborative problem solving. And we’ve been trained in solving problems in collaborations! It’s sort of our whole thing.
Managing Individuals
What To Do When Your Feedback Doesn’t Land - Lara Hogan
Feedback often doesn’t require much of a conversation. Done well, feedback is lots of tiny little nudges (mostly positive!). If any one of those nudges doesn’t really register with the team member, or is misunderstood, well, it’s not a big deal.
Sometimes though it does take some conversation. Maybe you just want to find out what happened in a situation you can make some adjustments elsewhere. Sometimes it’s because the feedback is more serious, or even just more complex. Hogan’s Feedback Equation is good for those; it ends with an open-ended question. (She has a bunch of good open-ended questions here).
Sometimes when these conversations happen and it’s more serious or more complex, the feedback doesn’t seem to land, or register, or… something. That might be because the team member doesn’t understand, or is getting defensive. If the conversation is awkward, it’s pretty natural for the manager to just want to wrap things up and get out of there, but we know that’s only putting off the problem.
Hogan has five steps for dealing with these situations:
Acknowledge the awkwardness
Create spaces and pauses for them to fill in
Ask them to reflect back what they heard
Ask open coaching questions
Set next steps
Managing Teams
What Good, Cash-Strapped Hiring Looks Like - Cedric Chin
Let’s talk a bit about giving interviews - Randy Au
Chin’s article talks about cash-strapped hiring with a few case studies. (We’ll probably see more articles about cash-strapped hiring in the coming year, as the market hits a tech correction and startups that were used to being able to raise money left right and center suddenly have to tighten their belts). The principles Chin sees in common for successful attempts are are:
You have a differentiated set of hiring criteria, and you are able to evaluate it during the hiring process.
You have some method for onboarding the talent you find in this way.
Because of 1 and 2, you are able to focus your hiring efforts on specific pools of talent.
You are willing and able to iterate on 1 through 3 above.
(The points about actively recruiting candidates that are likely to match the criteria are very relevant, too. Always be on the lookout for people in the community who might be good team members if the timing worked out.)
Point two, successful onboarding, is vital. I’m increasingly certain that hiring and onboarding are the same thing. In fact, starting the hiring process from picturing the end of the onboarding process - say four months in, the person is now a successful part of the team doing the job - is the way to go. Then back out the onboarding process. Then start putting together a list of hiring criteria for the job ad.
And for hiring criteria - I can’t stress enough the importance of point 1, tuning the hiring criteria to the actual work and the team. I have seen too many research computing and data teams hire against a laundry list of specific technical knowledge that might well be handy (but can easily be learned) while not actually evaluating how well the candidate would likely actually do the real, day-to-day job.
Au talks about something sort of skimmed over in Chin’s article - the interview process. Actually evaluating the candidate against the hiring criteria.
Make sure you’ve got your objective hiring bars and grading rubrics articulated and agreed upon by everyone
Remember that interviews are high stress, high stakes environment
Take home work is probably biassed, as is whiteboard coading
Basing questions off the real job is often a good idea
But don’t ask people to do free work for you
Please test your questions out on someone first
Finally, you’re going to be bad the first dozen times. Practice.
Getting the hiring bars and rubrics agreed to across everyone who’s going to interview is a fantastic opportunity to make sure the whole team is on board with what the new candidate’s job will actually be, and to help them develop their interviewing skills.
Also, we’re in science - calibrate your devices! Test the questions you’re going to ask on people who you know are confident would be good team members. If they stumble to get the question answered adequately in the time allotted, then adjust accordingly.
Rands Leadership Slack engineering-effectiveness: A curated summary of shared tips & resources - Curated by Jasmine Robinson
I’ve mentioned the Rands Leadership Slack here a few times, where we’re slowly growing a research-computing-and-data channel. That channel doesn’t have enough of a critical mass yet to keep conversations going naturally, but luckily there’s so much else going on in the slack that there’s always something to read or a conversation to be a part of.
One new Rands’er has gone through the past five years of conversation on the Engineering Effectiveness channel and distilled the past five years of discussions, advice, and suggested resources into best practices, tips, resources, FAQs, and more: it’s well worth a look if you’re wondering how to make technical teams more productive and effective.
(The Rands slack operates under Chatham House rules, so distilling discussion from there is explicitly allowed as long as it’s not attributed).
Random
I’ve wanted something like this for years - why don’t we have something like this in IDEs? A prototype text editor which allows drawing and rendering of line diagrams in SVG along with text. It’s 2022, why do we still have to use ASCII art to draw our in-code diagrams?
Web apps are cool, I guess, and so are CLI tools, but what about tools that run over DNS?
As time goes on, the implementations of “Wordle for X” stretch further and further into the past - Wordle in Pascal for Multics (an OS from the late 60s).
Web browsers are extremely complicated pieces of software - here’s a book walking through building a simple one in 1,000 lines of Python.
Deep Learning is taking over a lot of things, but not in-terminal games without complete knowledge - symbolic methods are still comfortably ahead in the 2021 NetHack challenge.
An old school BASIC interpreter + DOS environment, reimagined as web app - EndBASIC.
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