A Book Club Guide to
The Psychology of Software Teams

Think of one moment at work where your emotional state visibly shaped your technical output (a good day or a bad one). What would it have looked like for your team to account for that? Make an if-then plan (“if I have a bad day, then I will…”) to take care of yourself on a bad day.

Think of a moment where you’ve seen a technical person or team successfully make their work more “visible and valued.” What barriers did they face in doing so? Is there any wisdom they would pass along to others? If you are that person, what advice would you give your younger self? To make it tangible, write down one concrete piece of advice, or even a whole letter, to your younger self.

Look at your team through the lens of all three traps (Brittle Productivity, Lone Genius, and Chilly Climate), then pick whichever one feels most salient right now. Name one concrete, observable sign of it (for example, a sprint that “succeeded” but left everyone wrecked; a story where one person is framed as the only source of breakthroughs; a cue about whose identity is really welcomed in the room). Then identify one small step you could take this week that would help break the thinking trap.

Look at a tech community you’re part of (an open-source project, a meetup, a Discord or forum, a professional network) through the same three traps. Pick whichever trap feels most salient. Brittle Productivity might appear in unpaid maintainers burning out while everyone praises the project’s “amazing momentum.” Lone Genius might show up in who gets thanked in the release notes versus who did the coordination and community work. Chilly Climate might be present in a community’s inside jokes, its default assumptions about who’s “actually technical,” or who stops showing up to events. Name one concrete sign of the trap, and then write down one thing you personally could do this month to interrupt it.

Think of a recent technical win on your team. Trace how many people’s contributions actually fed into it, even indirectly. Who tends to get the credit, and does that match the trace?

Identify a hiring or performance review practice you’ve encountered that assumes individual, fixed ability. How might it look different if it assumed ability is shaped by environment and support?

Pick a recent piece of code or a solution you’re proud of and trace your thinking’s lineage. How much of it was genuinely built from scratch, versus adapted from documentation, Stack Overflow, a coworker’s earlier PR, or an open-source library? What does that trace tell you about how “individual” your work actually was?

Take a piece of praise you’ve recently given or received that emphasized talent or outcome (“you’re a natural at this,” “great job hitting the deadline”). Rewrite it to emphasize effort, strategy, or improvement instead.

Bring to mind a recent moment when your technical work did something negative you didn’t expect, like created a bug in production, put you through a review that went badly, or locked you into a design you now regret. Instead of moving past it, sit with it for a minute. Try to recreate the feeling you had when you realized that negative thing was happening. Now, shift your attention to how you're thinking about yourself, and try saying these three sentences about that moment. This might feel a little cheesy at first, but notice if it has an impact as you try on these thoughts:

Think back to a version of yourself before your current skills became tied to evaluation, your own equivalent of Shaun’s “motivated kid” who loved the puzzle before it became a performance. Pick one piece of technical work this week with nothing riding on it (a side project, an unfamiliar language, a bug with no deadline attached). Deliberately set a mastery goal for it instead of a performance goal: define success as “what did I learn” or “how did my strategy improve” rather than “did this look impressive” or “did I get it right on the first try.”

Think of someone on a past team you were in coalition with, even if you didn’t always agree with them. What made that relationship work? How did it change your thinking? If you’re still in contact, make a plan to reach out to that person and thank them.

Think of a disagreement with a group that you’re experiencing or seeing right now. Whether or not you agree, take two minutes to experiment with reframing the conflict as coming from loyal dissent, putting it into the context of a push for better coming from someone committed to the team’s success. Try writing a few sentences from the dissenter’s point of view.

Pick one causal claim currently floating around your technical community or workplace (“X practice makes us more productive,” “Y tool improves quality”). Write out the claim. Then, see if you can answer these questions for it: what specific effect is this, over what timeframe? What evidence could you realistically get to assess it? What would a counterfactual comparison look like? Is there an important confound (a third variable that changes the relationship) that might change whether you get this effect?

If you could run one evidence project inside your own team or org, what question would you actually want answered?

Write down one sentence you could say in your next team meeting that puts one of this book’s ideas into practice.

Take two minutes to write down a concrete value that matters to you. It can be broad, but should be personal to you. For instance, you might consider family, friendships, craft, honesty, care for other people, learning as a lifelong value, or intellectual fulfillment. Don’t necessarily try to connect it to your work; just write about why the value matters to you and one specific way it has shown up in your life. Then think about your technical work. How might you show up for and demonstrate this value in your specific role, workplace, or life in technical communities?