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.
Why focus on psychological safety?
Laundry backpressure
It’s been a recurring problem in our house – clean laundry starts piling up on the bed in the spare bedroom, and we always intend to finish sorting & putting it away… but it mostly doesn’t happen until there’s an intimidating heap and we have to dedicate serious time to a rescue effort.
We’re all busy – two parents with work to do, two kids with homework & music practice waiting, two cats busy with their mysterious cat priorities. Food things, friend things… Every now & then, we manage to get ahead of it, but soon, when we’re choosing between “sort & put away laundry” vs. all the important stuff… the laundry starts to collect again.
I came up with a strategy yesterday, though, inspired by a concept I’m familiar with from work: backpressure.
Interview: Parents In Tech
I spoke for more than an hour last month with Morgan at ParentsInTech.com — then he was tasked with winnowing it down to a blog post of a reasonable duration.
http://parentsintech.com/rob-whelan-cto-of-patients-know-best-and-dad-to-juniali-and-rumika/
I have somewhat mixed feelings about it — what comes across the most is that I’m bursting with advice about parenting; lessons I’ve learned, things I’ve noticed.. I’m fascinated by the evolving relationships between parents and children (and where they go right, and where they go wrong), and I could talk about them for hours.
I didn’t talk as much as I should have specifically about how to be an involved parent in the tech startup world in general, and in particular how our work environment at PKB enables that… I’ll add more thoughts here, briefly.
Waiting is horrible. So don’t do it.
The NY Times has an writeup today on the psychology of waiting – mostly, waiting in line.
Here’s the wrap-up at the end:
The dominant cost of waiting is an emotional one: stress, boredom, that nagging sensation that one’s life is slipping away. The last thing we want to do with our dwindling leisure time is squander it in stasis. We’ll never eliminate lines altogether, but a better understanding of the psychology of waiting can help make those inevitable delays that inject themselves into our daily lives a touch more bearable. And when all else fails, bring a book.
Understand why it’s unpleasant? Bring a book? Meh.
Here’s my counter-offer: waiting is optional; don’t do it.
I’m not talking about finding clever ways to jump the queue or get VIP treatment. This is simpler (and more practicable).
You can do whatever you like in a waiting room, in a supermarket queue, in your car while stuck behind a truck on a winding back road, etc. etc. — anything, as long as you can do it in your head.
If this sounds like a joke, or that it wraps a cruel assumption that you’re some kind of mental Olympian, bear with me for just a moment while I connect some dots.
What’s wrong with making money from advertising?
Any hardcore developer must be dying to work at Google, Twitter, or Facebook, right? Well, no; see this post by Dave Copeland, “Why I’d never work for Google, Twitter, or Facebook”.
I generally agree with his points; if your core business (where the money comes from) is advertising, your customers are the businesses who pay for the ads, and — to put it bluntly — your users are your product. However sophisticated the services you offer to keep your users around (viewing ads…), your relationship with your user/product is unavoidably marred by this fact. “I’m giving you things, on the assumption that I can convince you to give sufficient money to my actual customers.”
As a developer, I’m not interested in pushing ads any more than Dave is (though the point is academic, since I’m not exactly being recruited by the “big three” — but the principle certainly influenced my job search last year).
It’s not just that I’m not interested in advertising, though. Any company’s actions in the world have myriad effects on lots of people, from tiny to grand scale, and delivering better and more effective advertising is a net negative.
My music doesn’t come in “genres”
I had an odd realization the other day; I ran across a new music streaming site – promising “interactive radio that will blow your mind” – but while scanning through the list of 50 or so categories of music to choose one matching my tastes, my interest rapidly waned. ALL of them looked bad to me. It was like going back in time 20 years and flipping through the free audio cassette bin at a suburban yard sale. I couldn’t imagine starting up an audio stream in any of these categories and liking what I heard. R&B?
At first I thought that maybe my musical tastes have just grown too weird and eclectic over the years, but there are plenty of tracks I like that are “popular”, or were popular 10 or 15 (or 100) years ago.
Here’s the catch, though — I don’t like categories. I don’t even like artists. Example: I like Radiohead — see, that’s totally mainstream! — but they have entire albums I’d just as soon skip past, and no single album I’d want to hear in its entirety. There are songs I’ve liked enough that I’ve listened them to death, and never want to hear them again.
Why Don’t Developers Like to Estimate Time Accurately?
I was reading this just now – Why Can’t Developers Estimate Time? – and realized the discussion leaves out some fairly important psychological factors that influence time estimates significantly.
As the developer, you focus on the risky bits — the parts that are technically difficult & complex, that use new APIs or new libraries you aren’t familiar with, that require designing a new UI, or matching very strict performance tolerances.
For these sections, developers (with a little training) can learn how to estimate as well as possible — it’s hard, we know it’s hard, and either we’ll say “that’ll take a long time” or we say “we’d better do a proof-of-concept first, because I’m not sure at all how that will go.”
Now we get to the rest of it — the trivial parts. Writing some simple tests, taking input, validating it, storing it, returning something else simple straight out of the database… it’s simple, it’s boring, and any developer on the team could do it.
But it always takes an embarrassingly long time (with the emphasis on “embarrassing”).
Your codebase is a user interface
Every developer has spent time working on at least one project that was rife with poorly or bizarrely-named variables/methods/types, dead code, impossibly long code blocks, misleading comments, contorted logic, ancient libraries and dependencies that are never upgraded, and worse.
“Someday,” of course, “we’ll clean that up” — but there are urgent features already promised to customers, urgent bugs, and of course everything is always running late because the codebase is so darn hard to work with.
So yeah, curse the earlier developers who made the first mistakes, right?