#42 - 13 Nov 2020
Task relevant maturity; we learn better when we choose;
Managing Teams
We Learn Faster When We Aren’t Told What Choices to Make - Michele Solis, Scientific American
A key responsibility of ours as managers is to make sure our team members are growing in their skills and abilities. Solis’ article summarizes recent work with simple game-like settings where participants learn, for instance, which symbol in the game is worth more. The authors demonstrate that the participants learn faster when its their choices that drive the learning rather than when they’re guided through the choices which show them the same things.
It’s important to delegate new tasks to team members, and while they’re learning - climbing up the responsibility ladder, or gaining experience managing increasingly complex projects - it’s our responsibility to provide guidance to team members and not leave them adrift. But we do that best by providing guardrails, not by controlling the steering wheel.
End Micromanagement: 6 Signs You’re a Micromanager (And What to Do Instead) - Dara Fontein
The Most Important Management Concept You’re Missing: Task Relevant Maturity - Lighthouse
Relatedly, one of the big questions new managers have is how much managing is too much - you don’t want to micromange. In research computing the default is to come down on the side of way, way too little managing.
These two articles read together I think help clarify things. Fontein’s article outlines common micromanaging signs, and I can almost guarantee that if you’re in research computing you don’t tick any of those boxes (except maybe “you hate delegating tasks”, but that’s a skill that needs some practice).
But when working with new people, especially junior staff, you do have to keep an eye on them as they progress. So how does that work?
The Lighthouse article on task relevant maturity (and other resources that have come up before - An Engineering Team where Everyone is a Leader and The Responsibility Ladder ) help clarify thinking around this. The idea isn’t to drop someone new into some big project and let them sink or swim; that’s not good management. But doing the work for them or rewriting their code isn’t good management either.
The idea is to give clear goals about what is to be achieved along with measures of success, and to let them run with it. Initially you follow up relatively closely - assessing the what’s not the how’s - and as they mature and demonstrate “task-relevant maturity” the training wheels slowly come off and they get more and more latitude and less oversight.