#148 - Task Relevant Maturity: or, "micromanaging" is context dependant
Plus: Accountability with compassion; Coaching teams as a whole; Async is more inclusive; Retrospective antipatterns; Becoming a lead-of-leads
I got an email this week from a reader asking about micromanagement, worried that they were too much or too little involved with their team members work.
I love this question!
The first, short answer - I’d bet money you’re not micromanaging. It does happen! We ex-researchers and scholars, we tend to either (a) not be able to let go of the work and so end up doing a lot of it ourselves and being super directive about what steps others should be doing, or (b) step way back and come up with ideas but let people do their own work, taking the same hands-off approach we take with collaborators, and manage with “benign neglect”.
Option (a) does happen, but (b) is much more common in the teams I’ve worked with or spoken to. That under-management is a problem, too. It can be convenient when everything’s clear and things are going well, but when there’s uncertainty or challenges, it just feels like being abandoned.
The longer answer starts asking a different but related question (occupational hazard). What does the right amount of focus on team members tasks look like? How closely should we be paying attention to how tasks are being done? What is “enough” structure and oversight?
We actually have pretty good answers for that!
But it’s not as simple as “always manage this way”.
The first important concept is task-relevant maturity, a term popularized in Andy Grove’s 1983 book. The key here is not the task itself or the person, but the match between the person and the task.
If the person has demonstrated success with that kind task in the past, then you focus more on making sure the objectives and expectations, are clear, focus on what rather than how, and offer support and input as needed.
On the other hand, if the person is new to this kind of task, then you offer more structure and guidance. For instance, if they’re quite new to this, even if it’s a larger project, you might hand out the work as pre-broken-down individual tasks, one at a time, and spend more time at the beginning on the expectations and what good looks like.
Roughly speaking, high levels of structure and oversight here means pre-digesting the work down into discrete tasks, and handing over those tasks one a time, with lots of background information. Medium levels mean handing out larger chunks of work, talking in terms of what more than how, and offering lots of context at the beginning and more support and encouragement or help on an as-needed basis. Low levels mean talking about objectives and expectations, and then only modest levels of involvement and check-ins.
Four key points:
What matters here isn’t the person’s experience in general, but their experience with this kind of work. If you have a very senior person who is completely new to this activity, you don’t just toss them in the deep end and wish them well. And if you have a very junior person who has already done a dozen of these tasks successfully, you don’t still need to be holding their hand through the process.
As the person gains experience with these kinds of tasks, the training wheels gradually come off. They’re building skills handling this type of work, and will require gradually less oversight and structure around it. This is a way of not just making sure tasks are done well but helping your team members grow.
It’s very possible (and becomes more likely as you grow more senior) that you’ll be handing off tasks that you’re not an expert in how to do. That’s fine! For more junior people, where they may need oversight and guidance on the how, it’s your responsibility to make sure they can get it - but it doesn’t have to be from you. One of your more senior team members can help with the mentoring on that part.
Regardless of how involved you have to be in the task definition and structure, you still monitor progress and make sure that things are going well. Asking probing questions is always appropriate; checking on agreed-upon goals and expectations at the level appropriate for the level of structure and oversight is a must. Grove has a great quote on this: “Regardless of what the [Task-Relevant Maturity] may be, the manager should always monitor a subordinate’s work closely enough to avoid surprises. The presence or absence of monitoring… is the difference between a supervisor’s delegating a task and abdicating it.”
Demonstrated Success In The Local Context
One thing I’d add to the usual definition of task-relevant maturity is that it’s important that the team member have demonstrated success in the local context before starting to reduce the amount of structure and oversight offered. Even a fairly experienced person, in a new job and a new organization, may struggle with doing something “the way we do things here”, whether that’s knowing who on other teams to talk to or knowing the expectations around certain kinds of work.
High-performing new team members who already have experience with a given kind of work won’t chafe at initially high levels of oversight and structure, as long as they know why it’s happening and as long as they do in fact see the structure and oversight go down after initial successes. This is just helping them succeed. It’s a specialized and perhaps delayed part of their onboarding process - you’re onboarding them onto this kind of work.
So even if someone has done something lots of times before elsewhere, start them off on the high-oversight side of things. If they do well they’ll rocket through the levels, will see you recognize that, and it will be more hands off in no time.
Riskiness of the Effort
Finally, if the effort is in some way unusually risky - it’s very high visibility, a mistake could be career-limiting or damaging to the team, there’s an unusually large amount of money or strategic interest involved - it’s your responsibility to dial up the structure and oversight the appropriate number of notches. It’s not kind or good management to put a team member in a situation where a simple mistake on their part could have outsized effects on them or their teammates.
By all means, if it’s high visibility and they get good results they should be the one to get the kudos. But it's just simple prudence to make sure there’s good guardrails in place before starting a risky endeavour, even if the team member has done this kind of work before in lower-stakes cases.
Resources I Really Like For This
One can’t really write about this topic on this without referring to High Output Management by Andy Grove
The 5-part Manager-Tools podcast series on The Responsibility Ladder takes a very fine-grained approach to what’s described here - whether you follow it or not it’s a very carefully thought out approach
Does this make sense? Have you seen other approaches to making sure team members are getting both the structure and oversight they need while still having the opportunity to grow in responsibility, and the freedom to make decisions about doing the work? Just hit “reply”, or email me at email@example.com and let me know! I love getting reader input and reader questions.
And now, on to the roundup!
Hold Your Team Accountable with Compassion, Not Fear - Liane Davey
I find a lot of people from research have a hard time holding their team members accountable (or helping the team learn to hold each other accountable, #128). Time and time again this turns out to be because no one has shown us how to do so without being a jerk about it.
But it’s possible! In fact, it’s done all the time.
This article ties in very nicely with the piece above about task-relevant maturity. Giving people tasks, especially tasks with a new responsibility for them, has to go hand-in-hand with kindly holding them accountable for the work.
The first point Davey makes is to make sure there’s clarity on expectations. I couldn’t agree more. One of the things I spend a lot of time on when I talk about project management is the project kickoff/charter - getting clarity and buy-in about what successful completion looks like at the very start. When you’re assigning tasks or delegating, you are kicking off a tiny project. Clear expectations are important for exactly the same reason as for a large one.
Other key points Davey makes:
Create psychological safety - it should be clear that it’s ok to struggle with the task, and in fact if it’s a growth opportunity for them you’d expect some degree of struggle
Maintain an appropriate level of attention
Adjust accordingly - give positive and negative feedback when appropriate, and adjust levels of attention as appropriate
But default towards being a coach throughout this, not directly involved in the work.
Allow for a graceful exit from the task if they’re struggling. By extension, if a team member is struggling on your team overall, allow for the possibility of a graceful exit from the role.
Coaching Your Team as a Collective Makes It Stronger - Sanyin Siang and Michael Canning
We’ve talked a lot about coaching (#56, #139) here, but typically in the “managing individuals” section. Siang and Canning tell us, with examples from the Osler Internal Medicine Training program at Johns Hopkins and the US Special Forces, about coaching a team at once (with the US special forces, with retrospectives, which are routine and referred to as “after action reviews”). Coaching the team collectively helps everyone learn from the problem, not just one person at a time, and helps the team get better at problem solving collectively.
Whether coaching an individual or a team, the approach is the same:
Focus on the problem, not any issues or solutions
Coach, don’t tell
Learn from both successes and failures - focusing only on one means missed opportunities to learn
State of Remote Work 2023 - Buffer
Buffer surveys remote workers, and finds that those who are working remote overwhelmingly (98%!) want to continue working remotely at least part of the time. What’s become clear over the past few years is that it’s not about the commute(only 12% of those in the buffer survey cite that as the biggest benefit) nor loving working from their own space (7%); it’s because of flexibility.
Flexibility of work is actually kind of orthogonal to location of workspace. But remote work allows for more asynchronous work, which leads to greater flexibility. Really, moving to asynchronous work with more collaboration around documents and fewer synchronous meetings, is necessary to fully take advantage the power of remote teams.
And doing so also makes for a more inclusive workspace, as Meyer describes.
Adults with disabilities, who make up 13% of the population in the United States, “have rarely been employed in such high numbers," Bloomberg reported in October.
We spoke to several people who told us how a remote, async-first work environment — free from daily commuting, back-to-back meetings, presenteeism, and “always-on” communication — has made it possible for them to manage health conditions, to be more present as a parent, or simply to produce better work, in ways a traditional work schedule did not.
Meyer lets a number of people share their stories, from one person who stutters very badly and is much happier with written communication, to neurodivergent employees or those with health conditions or even just those with young children.
Project and Technical Leadership
Retrospectives Antipatterns - Aino Corry
As you know (#128), I think retrospectives are pretty key to having teams that function as teams, and they’re a vital mechanism for leverage - for each time going through something to get that much better, in a compounding way, for the next time.
But unfortunately just scheduling a meeting called a retrospective isn’t enough on its own. They have to be run well.
Corry describes some experiences she’s seen that have derailed retrospectives. There’s a helpful sidebar to the article that lays out the five key (and distinct) stages of a retrospective:
Set the stage - intro, theme, and any follow up on previous TODOs
Gather data - everything that's going well and poorly
Generate insights - what’s behind the data, what’s the underlying problem
Decide what to do
Close the retrospective with a concrete plan for the TODOs.
Three antipatterns she describes, with stories, are:
Trying to “save time” by going straight to solutions rather than gathering data and identifying underlying problems(solution: don’t do that, gather the data first)
Spending time focussing on things that can’t be helped (solution: divide topics into things that the team do things about, things they can try to influence, or things that are external boundary conditions and can’t be changed)
Having the meetings dominated by one or two possibly well-meaning people who do most of the talking (solution:either very active facilitation and feedback, and/or structuring the conversation in such a way that one person can’t dominate - breakout groups, more writing, etc.)
Managing Your Own Career
Advice for new directors - Jade Rubick
On a recent podcast, I heard Jason Warner (who turned GitHub around after being at Heroku for years) talk about a director as being not a manager++ but a vice president--. While the titles don’t quite map to our line of work, that’s by far the best one-line description of the nature of the role that I’ve heard.
Like going from a team member to a manager, going from a first-line manager to a lead-of-leads (whether that’s titled a senior manager or a director at your org) is again a career change, not merely a promotion. Rubick covers that in some detail in a good article for anyone thinking of becoming a director.
The biggest difference is that now you’re not even overseeing the work, much less doing it.
Suddenly your success is based on how well your managers are running their projects. Your success is based on how well they hire. Your success is based on the improvements they make on their team.
All of your influence on what’s being done is with at least one other person as an intermediary. Rubick says that makes one-on-ones even more important.
The sooner you’ve mastered the basics of your own role as a manager and moved on to more advanced work like making yourself less necessary by creating the processes by which good decisions get made in your absence, the easier this transition will become.
Other key points made by Rubick:
A lot of your job is training managers
The biggest skill to learn is sensing your organization - the issue of managerial sensory deprivation (#117) is even more acute at the director level and above
It’s important to focus on systems
More evidence from the “experience as a researcher gives you superpowers” files: new entrepreneurs taught a scientific approach to testing hypotheses perform better.
You need a (free) Adobe account, but Adobe’s podcasting service (!?!) has an easy free microphone check page which lets you know if you’re too far from the mic, whether gain is too high, and how echo and background noise is. Very handy.
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,