Yearly Archives: 2020
Transparency, diversity, and psychological safety
This hadn’t been the post I planned next, but I’m preoccupied with current political & social upheaval. So: today I’m posting about the leverage companies have to both improve their developer teams and society as a whole.
I’ll just lay out my current mental model — if this is useful to you, excellent. If you see flaws or can offer refinements, even better. Note on context: I’ve only ever worked in smallish companies; some dynamics change in larger orgs.
My basic thesis:
- By default, most developer teams will tend towards poor diversity & biased people decisions, even with effort to do better — and even if they are (somehow) bias-free, it will still LOOK like there’s a problem. That sabotages the team image for potential hires (plus you simply lose out on the well-studied benefits of a diverse team).
- Once a startup has grown into a medium-sized company that took the default, not-great path, it’s expensive & difficult to correct the trajectory.
- But the crucial corrections will make any team more effective; so even if you feel that a startup can’t spare focus to work on diversity, keep reading.
Super-short, skip-to-the-ending version of a better approach:
- Convert your processes to be concrete, transparent & data-driven
- Share them (internally, then publicly)
- Result: you’ll drive both real diversity, equity & inclusion
- …and take huge steps to foster team psychological safety
More details & specific guidance: read on.
Poor communication red flags
A “code smell” in software dev is a case where it may not be perfectly clear what is wrong with a section of code or a design, but … there’s definitely something, and the team should dig into it before going ahead. There are similar red flags that communication in your team isn’t happening as it should — and you should take a closer look, whether you’re leading the team or not.
Peter Senge’s focus on systems thinking is very relevant here (see “The Fifth Discipline”; a classic). A team (and a company) is a complex system that’s not self-correcting/improving by default; if you just leave your communication culture to develop on its own, this system will lose energy & focus to random communication failures, and break down dramatically under strain — i.e., at the worst possible time.
Here’s a list of 8 red flags that your team isn’t communicating effectively — see which ones you recognize, and we’ll review some strategies to address them.
1. You’re nearing a secret tipping point
There’s a growing problem; when it hits a tipping point, then you’ll take some irrevocable, probably harmful action.
What?! That’s the 2nd time this week he’s gotten into some kind of pissing match with his team lead. I don’t know what’s gotten into him lately, but this is the last straw; he’s got to go.
Building effective distributed teams: series intro
Audience: Anyone leading or working on a distributed software development team keen to become more effective, motivated and fulfilled.
I’ve spent the last decade working full-time+ on a fully-remote healthcare startup, and stepping away of that particular mad plate-spinning exercise has been surreal. I originally joined the company straight from my own ed tech solo startup, so really, it’s been a very long time since I’ve been able to wake up in the morning without that threatening cloud of so many things to do!! 😱 looming over my head.
Untangling a hard problem triggers an urge to help others avoid it, and so I have scores of essays & articles that I’ve started over the years, but then set aside for more urgent tasks. Over the past few weeks, I’ve been taking time to read & reflect, firstly, and to revisit some of those notes.
Topics are all over the place, circling around remote software dev & management (my life for 17 years, now), branching off into other topics that interest me (technical or not).
But I’ll start with the most important one: building effective remote dev teams, founded on psychological safety & robust human feedback loops.