#90 - 5 Nov 2021
Shaking off the status quo; Being directive without being a jerk; Stop looking for mentors; Software team productivity
In our team there’s been a lot of passages lately - a paper for our original work is (finally!) coming out, as our new version is (finally!) coming together; we’re gearing up for a new batch of co-ops as our current co-ops are starting to document and getting ready to present their work; a project manager is joining the team for the first time now that the effort has reached a size and scope that it needs one (well, it needed one a year ago, but here we are).
These passages - and especially the influx of new people, new tasks, new scope - are really important for a team’s well being. Stasis isn’t stable; systems, including systems of people, are either growing or stagnating.
In academia, where we were trained, it’s far too easy for groups to become very comfortable with “the way we do things”, and set in their ways. As Boulanger points out in the first article in the roundup, that can quickly lead to problems not being addressed - or even really noticed any more - and eventually people both within the team and “clients” of the team starting to drift away. In fact, I was talking to a colleague this week about one group’s services becoming ossified to the point where consumers of those services started moving to those of a different and newer group - the first group didn’t take feedback or feature requests seriously, and now there’s a real chance it will simply be disbanded (or, maybe worse, left go on indefinitely with less and less actual purpose).
Stagnation isn’t inevitable, but it takes active and continual effort to avoid. It should be easy - there’s a constant influx of new ideas available. But ideas don’t adopt themselves, and practices don’t adapt themselves. They’re adopted and adapted in units of teams, and one of our important jobs as managers and leads is balancing real needs for degrees of stability and certainty with equally real needs for change and growth. Balancing openness with continuity is hard, but vital.
And now, the roundup:
Why The Status Quo Is So Hard To Change In Engineering Teams - Antoine Boulanger
Boulanger here points out a situation that is especially common in academia, with slow-growing teams where individual team members have long tenure. The issue is that a team gets so used to the way things are they don’t even see it any more, and forget that things don’t have to be this way. There can be a sort of learned helplessness to the procedural, technical, and complexity problems within an organization.
Having new people come in regularly - even short term team members like interns - can be very helpful for this, as long as they are comfortable making comments like “why is X? Isn’t that bad?” and the team takes the points they raise seriously.
Boulanger has recommendations for us managers or leads:
Regularly get into your team’s shoes
Notice when people stop complaining about an issue - this can be a negative, not a problem
Create some metrics around known issues so you can see if they’re getting better or if the team is just getting more inured to them
There are a lot of strengths that can come from a long-lived stable team, if you’re careful, but the default outcome is stagnation. The manager, and the team, has to be constantly and actively looking for things to improve and areas in which to grow to prevent the default.
You can be directive without being a jerk - Lara Hogan
Being Nice and Effective - Subbu Allamaraj
I think one of the hardest things for new managers - especially those coming from the very hands-off collegial culture of research - is determining the right amount of directiveness appropriate for a given situation. The usual failure modes, in order of the frequency which I see them, is the very common laissez-faire absence of direction and the less common tech-lead-becomes-manager “do this, this, then that, and my way of doing it is exactly like this. In fact, why don’t I just…”
Hogan’s article is a followup to an earlier one, fixing a team going in circles. So here it’s a big topic of setting some direction for an entire team at once. But the approach works for a particular team member, too - being specific about whose job is what, focussing on the important thing (the team’s work) and not about individuals, and firmly but kindly applying direction at the level needed - whether that’s on tasks or goals or somewhere in between.
Allamaraj points out that being effective doesn’t necessarily mean not being nice, and being “nice” isn’t necessarily an end in itself anyway; we want to be kind, and sometimes “nice” gets used as meaning sort of inoffensive. Letting someone trudge aimlessly in circles while just smiling and not saying directive may seem from a distance like ‘nice’ but it’s certainly not kind.
Well-researched advice on software team productivity - Ari-Pekka Koponen, Swarmia
Your team may not be a software development team, but I bet you wonder about the productivity of your team.
Management is hard, management of something as complex and ambiguous as a team of humans, but that doesn’t mean we don’t know anything. There has been a lot of research on what works for making teams work well, and recently particularly in the area of software development. I think other teams can learn from this!
It doesn’t mean there are cookie-cutter solutions for anything, but we do have good guidelines. Koponen walks us through several well-supported (and in some cases ongoing) reports, many of which readers of this newsletter will have already known about
Project Aristotle (#46) - The follow up to Google’s Project Oxygen, going beyond the effect of single managers to team behaviours. They found that five factors were very strongly correlated with high performing teams
Psychological safety - team members feeling comfortable speaking up
Dependability of other team members
Structure and clarity
Work having meaning, and
Work having impact
DevOps Research and Assessment (DORA) metrics - These are aimed for those developing and operating software systems, but many of them are relevant to those writing and releasing software: they find that teams that are performing well have:
High deployment frequency - it’s easy to update the software and keep it working
Low Mean Lead Time for Changes
Low Change Failure Rate for changes to need to be rolled back
Low Time to Recovery for the times that errors do occur
Satisfaction and well-being
Communication & Collaboration
Efficiency & Flow
And most importantly, Retrospectives - learning and adapting practices based on what is actually happening on your team - allows you to tune.
What kinds of things would “high productivity” entail for your team? Or are you not sure? Email me at firstname.lastname@example.org; I’d love to hear from you.
Managing Your Own Career
Stop Looking For Mentors - Stay SaaSy
We could all use a bit more mentorship, but searching for A Mentor may make it harder to get the input we need. This article suggests making it easier on yourself:
Instead of looking for a mentor, just find somebody who can answer some questions you have. Then, if you think they can answer some more, ask them again. In reality, a mentor is mostly just somebody that answers questions more than once. That’s it. It’s not cinematic.
Lovely explanation of Bezier curves, splines, and smooth surfaces.
Fascinating look at the data infrastructure around python environments that have grown over time in some banks: Bank Python.
Causing data leaks via maliciously-crafted log messages.