#108 - Management sensory deprivation
Plus: Build teams, don't collect individuals; Progression ladders; The management/IC pendulum
Hi!
I’ve long tried to describe the sudden disorientation of losing immediate feedback that comes with being a first-time manager. Recently I heard the term “managerial sensory deprivation”, and I think that’s a useful phrase. When you’re hands-on doing the work, you get immediate, almost tactile feedback with what you’re doing. As a manager, any action you take has only indirect results that could take days, weeks, or months to really play out. And by that time, it’s hard to connect it unambigiously to something you’ve done.
Your work senses are getting no signal back, or weak signals seemingly unconnected to what you’re currently doing. You’re feeling a kind of sensory deprivation. And wikipedia helpfully reminds us that “extended or forced sensory deprivation can result in extreme anxiety, hallucinations, bizarre thoughts, temporary senselessness, and depression”.
This has come to mind lately being a new part of a big organization and, frankly, having no idea what I’m doing yet. I’m accomplishing stuff, but is it the right stuff? Is it having any kind of impact? If yes, is that impact positive? How and when will I know? Having moved organizations (and sectors!) I’ve again lost my bearings and my feedback mechanism. It’s apparently not an unusual situation; I heard the same thing from a reader who I talked with earlier this week, who’s also in a new job. (By the way, I love hearing from Manager, Ph.D. readers - never hesitate to email, or even book a quick chat.)
Gentle reader, I would love to tell you that I’ve cracked this code, and there’s this one weird trick you can do to find out if your management interventions are working or if you’re doing the right things at a new job. I haven’t.
But there are two things you can do, which take time and effort and are very much imperfect.
The first is to try to attune your senses to the new environment. This is slow and messy and tiring. It means paying very close attention to what’s going on, taking notes of what’s currently happening, what’s changing (for better or worse), and taking notes so that you can track those changes over the longer timescales you have to adjust to. You can’t possibly track everything, so you have to identify what you find to be notable, and then choose some particular signals either you feel are important or that those around you seem to act as if are important and track those. Over time we can train our senses to respond to the new environment.
The second is active sensing - absent being able to passively accurately sense the new surroundings, to actively send out probes. Since flapping around and whooping ultrasonically like a bat probably won’t work for us, we’re reduced to asking questions of our colleagues and stakeholders.
Asking questions is less slow, but no less messy or tiring. People’s answers will be inconsistent, and they are unlikely to be willing or able to tell you “you should do X, Y, then Z” or “This thing you’re doing is working, this other thing isn’t”. There’s three approaches I like to take to handling asking these questions (and handling the answers) in this environment.
The first is that being new is basically a license to ask unlimited questions, of pretty much anyone you want. “Hi, sorry but I’m new here/a new manager here, can I ask you a queestion?” is basically impossible for someone of good will to say no to. And you can ask the most ridiculously basic-seeming questions - it’s amazing, and you should absolutely take advantage of this. After three or four months it may well feel weird for you to ask someone you wouldn’t normally interact with an off-the-wall question, but it is completely fair game, almost expected of you, for the first few months.
The second is that people love giving advice. They may hate giving feedback, but they love giving advice. An questions you can pose as a request for advice will give you long answers to chew over. “What advice would you give me for…”, “How would you recommend a new person do this ” or “How would you handle this situation…”
The third is that people are pretty good at identifying that a problem exists in some area, but we’re actually pretty rubbish at diagnosing it precisely, much less coming up with a solution on the spur of the moment. So if you start getting feedback that something isn’t working, or even directly told you should do X instead, take the input seriously but not necessarily literally. If you hear from more than one person that that there’s something wrong in the same broad area, then there’s almost certainly a problem there! But it might easily not be what they describe. And if they’ve suggested a solution it might be the right one, but it’s at least worth thinking of alternatives. Take the input as data to be examined more closely and to direct further investigations.
Of course, the two approaches, passively taking notes and actively asking questions, work together. You can use the answers you get to train your passive sense for what’s going on, and the results of your noting and paying attention to inform your questions.
Are there other approaches you’ve found useful, when starting as a manager or just starting a new job? Or any suggestions for mentoring a new manager? Let us know — just hit reply or email jonathan@managerphd.com.
And now, on to the roundup!
Managing Teams
The Cone Model for Teams’ Support Network - Shy Alter
As managers and leaders we develop, and are responsible for, a team, not a list of individuals. A team is a group of people that support each other and hold each other accountable, not just a set of people with similar email addresses who report up to the same manager.
And yet an awful lot of management training and writing focuses solely on interactions between the manager and each individual team member. That’s vitally important, and an excellent place to start. You have to get the basics of being a manager right before focussing on strengthening teams. When I’m talking to new managers I often bring up Google’s Project Oxygen, which focussed on basic manager skills, first - but they followed that up with Project Aristotle, which was about higher performing teams as a whole. They found five key determiners of high performing teams:
Psychological safety - team members feel comfortable to take risks, raise sensitive points, and try new things
Dependability - peers reliably complete quality work on time
Structure and clarity - expectations are clear
Meaning - the work as a whole is meaningful to the team members
Impact - team members can see their contribution
For almost all of these, the within-team dynamics play as big a role as the team member-manager dynamics.
Here the alter makes the point that even from a technical point of view, you can’t meet all your team needs, If you uncover needs for your team members in one-on-ones and then look for coaching and mentoring opportunities between team members, you’re now developing your team in two ways: building their coaching/mentoring skills and their technical skills.
The nice thing about this of course is as the team grows, the amount of time you can spend on each team member drops as 1/N, but the amount of time available for other team members to spend on each other stays almost constant as (N-1)/N…
And there’s no reason why peer-to-peer coaching, mentoring, and teaching has to be constrained to within one team. Have you seen (or do you have) good peer knowledge-sharing and coaching setups? Anything you want to share with other readers? Let us know!
Don’t Hire for Culture Fit - Ruchika Tulshyan, SHRM Executive Network
I agree with everything in this article; “Culture Fit” too often means “like us”. So when people don’t give any better reason than “culture fit” for not wanting to hire a candidate, it ends up being wildly exclusionary. It’s also counterproductive! When you’re hiring, you want to grow the team not just in numbers but in capability, and hiring more of the same doesn’t get you there. As Tulshyan says, culture add is a good and useful thing.
There are also a number of behaviours and skills particular to a team which are absolutely worth making explicit and turning into hiring criteria, and those often get put under “cultural fit”. Those are important, and worth keeping but maybe we need a more specific term. For instance, for staff in a research team, it’s common (not universal, but common) that to succeed, a new hire will need to be much more comfortable with uncertainty and under-specified projects than would be common at the same level of seniority elsewhere. That’s a perfectly reasonable requirement to assess against in the name of cultural fit. Any other behavioural or communication skills and behaviours that can be called out with enough specificity to be unambiguously evaluated are worth considering.
As with all potential requirements, you should filter by “would a person really not succeed here if they didn’t have this?” If it’s not something that would stand in the way of their or the team’s success, it oughtn’t be a criteria.
For those who need ammunition for their case to continue at least hybrid remote work policies in an academic institution, maybe a randomized case-control study will help - from Nick Bloom and Roubing Han at Stanford and James Liang at Fudan:
A large multinational randomized 3-2 hybrid WFH vs 5 days per week in the office for 1600 professional graduate employees for six months. They found three results: (1) 35% reductions in quit rates and 12% reduction in sick leave; (2) No impact on performance or promotions; (3) Employees shifted work from WFH days to evenings and weekend (“flexitime”). The results were so positive the firm immediately rolled-out hybrid WFH to all divisions.
Expect to see a lot of these studies as companies move back to work. I’m particularly interested in studies going the other way - comparing pure remote work to hybrid in-office. Let me know if you see one!
Building an SRE Career Progression Framework - Ethan Motion
Whether it’s for research software, systems, data management, or data science, a lot of groups are trying to figure out formal or informal career progression pathways for individual contributors. As a manager, you can work with individuals in their one-on-ones to find out where they are interested in and ready to grow, and give them opportunities at that intersection. But how do you start thinking about career progression at the whole-team or multi-team level?
Motion describes a process of bringing together a piece of an organization to hash out a framework of levels on which to hang development pathways. Most importantly, he suggests defining the levels in broad behavioural terms:
Level 1: seeks to understand, attends, shadows, recognizes
Level 3: builds, designs, fosters, implements, applies expertise
Level 5: pioneers, promotes, researchers, informs leadership
I’ve seen threads.com come up in a couple of different conversations recently - is anyone using tools like that for discussions that you want to be less ephemeral than e.g. slack discussions? Text-based discussions leading up to decisions (as with architectural decision records) where the discussion is an important part of the documentation you want to maintain, and so things like Google Docs/Word comments aren’t right? Or do people use google docs or Git{Hub,Lab} with PRs for this sort of thing? Anything else for asynchronous meetings/discussions that you’ve found useful?
Managing Your Own Career
Twin Anxieties of the Engineer/Manager Pendulum - Charity Majors
As I’m decidedly back on the IC side of this particular pendulum, this has been on my mind a little bit.
Majors raises two anxieties she’s heard people have with this: “What if I never get another shot at people management”, and “am I too rusty to go back”. In both cases, her advice lines of strongly with my experience.
For the first one, you’ll have to have to actively fight off opportunities to go back into management. “Once a manager, marked for life as a manager” she says, and she’s 100% right.
For the second, she points out that you do get rusty, and if you went into management too early before you really had a change to build very strong technical skills, it could be hard:
Never, ever accept a managerial role until you are already solidly senior as an engineer. To me this means at least seven years or more writing and shipping code; definitely, absolutely no less than five.
But after that, it comes back, especially if you try to keep up a bit of fluency.
Most importantly, though, she talks about useful it is to have people with strong technical and people leadership skills:
If you’re a good manager it’s actually nearly impossible to hide that you have the skills, because of the way it infuses your work and everything that you do as an IC. You get better at prioritization, more attuned to the needs of the business, and restless about work that doesn’t materially move the business forward. You get better at asking questions about why things need to be done and at communicating with stakeholders. You get better at motivating the people you work with, understanding their motivations and your own, and mediating conflicts or putting a damper on drama between peers. People come to you for advice and may seem to just do what you say, or go where you point.
Random
See, this is why wordle 286 ended my winning streak. Wordle is NP-hard. Even knowing the right minimum number of guesses is NP-hard. It wasn’t that I got “OUT” too quickly and flailed too long to come up with SNOUT.
Oh sure, Jupyter is cool and all, but wouldn’t it be cool to have notebooks that support a prolog-derived language? Meet Percival, the notebook for datalog.
In the market for a multi-process 16 core 83 MHz Z80 laptop running CP/NOS implemented in an FPGA? Welcome to the Zedripper.
Something a little more modern? Ok, a full-featured classic 68K Mac in your browser. MacOS8.app.
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