#117 - 18 Jun 2022
Changes as a team grows; conflict management; not everything's your job;
Managing Teams
Developing Leaders: 6 Critical Things You Must Do When Your Team Grows Too Big - Lighthouse
A lot of begin our techincal leadership/management career by us growing with a team - we start off as effectively the senior sysadmin/data scientist/software developer on a team of two or three, and then the team grows. While numbers vary a bit based on the work of the team, below is a pretty typical trajectory with team size:
2-3: You’re mostly a team lead, supervising and directing technical work
4-6: You’re becoming a full-time manager; the team has to be collectively more technically independent day-to-day
7-9: Getting pretty big: you’re starting to need to identify technical leads for sub-teams
10+: Sub teams require increasing independence; another manager going to be needed soon
Obviously, this being the research world, no one talks us through any of that, or the different skills needed at each level.
One big reason why this is a problem is that not only do our skills need to be growing during this evolution, so do our team members’; at each step of this path the team is taking on a greater level of responsibility. Even at that 2-3 person team size, they’d benefit from us coaching them to take on new responsibilities as the team grows to the point where we’re full time managers; and then you need to identify and grow team leads, and eventually find a peer manager.
This blog from lighthouse covers things we’ve talked about before, but it’s a good overview of the process above, covering:
Let go - you’re going to have to give up responsibilities
Look for the leaders already on your team - who’s doing glue work already?
(Assuming they’re interested) give them opportunities and set them up for success
Coach and develop them
Once they are managing people, meet with your new skips occasionally
Conflict Management in the Workplace: How to Deal with Conflict as a Manager - Management30
Respectful, healthy conflict is fine, even good, for a team - it’s essential, even, in the storming phase of the team formation cycle. But it does have to be managed, or at least monitored, and acknowledged. There are some points here to work through if the conflict becomes A Big Thing, which needn’t be the case. But even for more quotidian cases, there’s a useful breakdown of types of conflict which are worth keeping in mind (especially since conflict can “look” like one when it’s really another)
Task Conflict – What needs to be done?
Process Conflict – How does it need to be done?
Status Conflict – Who needs to do it?
Relationship Conflict – When it’s getting personal
And the fact that explicitly calling the conflict out is the first step in moving to a resolution.
Not My Job - Silvia Botros
As a junior IC, one has the comfort of knowing exactly what one’s job is. As the scope of one’s responsibility grows, that stops being true - there’s a lot more to potentially be responsible for. But that doesn’t mean we’re responsible for everything and anything! Botros writes to push back against well-intentioned but dangerously un-nuanced points of view like `There is no “that’s my job” anymore’.
She makes an excellent and useful distinction between glue work and “gap filling”. Glue work is something all managers and technical leads genuinely are responsible for; being the connective tissue which stitches together individuals and teams and external stakeholders to make progress to a common goal. But sometimes there are gaps - missing expertise, absent leadership, no one to take on needed work - and we can’t selflessly fling ourselves into every such breach. That way leads to burnout for us, while the underlying problem remains unfixed.
Botros counsels being vigilant to avoid this, and to stay in contact with your manager and leadership to make sure the work you’re doing lines up with what your organization needs most:
Assessing whether what you are doing day to day needs to be an intentional process, something you and your manager re-assess routinely and compare to your goals and the organization goals. Be very aware of being pulled into projects with no measurable milestones. […]. You should use your experience and influence to shed a light on gaps and risks. But you cannot fix them all.
In our line of work I think this article and its recommendations are important not just at the individual level, but for whole teams. We’re doing our work because we want to advance science. There’s a noble but foolhardy tendency for research computing and data teams to want to jump in and solve any researchers problem even tangentially connected to our remit. But we can’t fill every gap. We advance science best by focussing on where we excel, doing our best work there, identifying gaps elsewhere, and then either flagging them to leadership or connecting researchers to other teams elsewhere. We can’t, and shouldn’t, do everything.
Random
A single beaver caused a massive, hours long cell and internet outage in northern British Columbia, Canada.
Generating true random numbers from bananas, by tracking the radioactive decay of potassium therein.
How fast can 1975’s 6502 processor transfer memory? About 57kB/s on the C64, up to 664.2kB/s with a new(!) 6502 motherboard.
Enabling Touch ID to authorize sudo on MacBooks.
Too young for that ARPANET/BITNET/early internet experience? Or just an oldster like me missing it? Welcome to telehack. (Anyone still running any MUDs?)
Decoding weird magic numbers, backwards compatible to to the Burroughs 5700, in old Fortran code.
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,
Jonatha