Skip to content

Latest commit

 

History

History
84 lines (44 loc) · 8.5 KB

why-you-need-a-wtf-notebook.md

File metadata and controls

84 lines (44 loc) · 8.5 KB
title date tags aliases
2024-04-25 - TIL - Why you need a "WTF Notebook"
2024-04-25 15:50:33 -0700
why-you-need-a-wtf-notebook
resources
til
today-i-learned
things-i-learned

2024-04-25 - TIL - Why you need a "WTF Notebook"

How to use a "WTF Notebook" to help you build a reputation as someone who's really effective at getting stuff done and avoid being someone who's complaining all the time.

Usage

Every time you join a new team, go to the next fresh page, and on top of that page write: "WTF - [Team Name]." Then make a note every time you run into something that makes you go "wtf," and a task every time you come up with something you want to change.

For two weeks, just do exactly that. Just write it down. Don't tell the team everything that you think they're doing wrong. You don't show up at retro with all the stuff you think they need to change. You just watch, and listen, and you write down everything that seems deeply weird.

This is a trick I picked up from reading Why you need a "WTF Notebook" who learned it from a team lead, who learned it from a previous lead of his in turn. It's one of the author's most powerful techniques for making changes on a team, and managing themselves while they do it. The following is a walk-through on how to use that list, and how it helps you to build a reputation as someone who's really effective at getting stuff done, and avoid being someone who's complaining all the time.

There's always stuff that makes you go "wtf" on a new team. The team talks for an hour in retro about a serious problem, and then leaves without making any action items. The tests don't run locally and no one seems to notice. Big chunks of the build board are always red. Only one person can do some critical, time-sensitive thing. The team is spending a bunch of time on some feature, but when you ask around no one can seems to know why it's important or how it'll help a customer.

Once you've got a nice big list, you start crossing things off. There are four reasons at this point where you might cross off something you've put on that list:

  1. There's actually a good reason for it
  2. The team is already working on a fix
  3. The team doesn't care about it
  4. It's really easy to fix

If the tests don't run locally, for instance, that might be a known issue that there's an ongoing effort to address. The team might do all of their work on virtual machines, and have a simple chat command that provisions those machines for them. Or they might have a pretty good continuous integration system and good habits around making small changes, so not being able to run the tests locally isn't stopping them from deploying multiple times a day.

Sometimes, it'll turn out that there's a really simple fix for some of the things you've identified. Maybe there's some documentation you can write, once you know where it is, or maybe there's an easy change once you find the right scripts. That's not always immediately obvious when you first see a problem. When you do see an easy fix, though, you can just go ahead and make it.

After a few weeks, though, you'll still have a bunch of weird, unresolved issues on that list. At this point you can start talking about it with other people on the team, the team lead, and your manager.

You can ask why things on the list are that way, and how they got to be that way. You're trying to establish credibility as someone who's genuinely curious and empathetic, who's patient, and who respects the expertise of their coworkers. That's the reputation that's going to let me make changes later.

Generally, you'll find out that the things that are problems you've noticed are around for one of a few reasons:

  1. The team hasn't noticed it
  2. The team has gotten used to it
  3. The problem is relatively new, and the old problem it replaced was much worse
  4. They don't know how to fix the problem
  5. They've tried to fix the problem before and failed

On a lot of teams, when you ask some questions about things that turn out to be in the first few questions, the person you ask will just fix them immediately. Or they'll help you figure out how to fix them. If it's a technical problem, that means writing a story or a ticket together, and then pairing to work on it. If it's more process or social, it means bringing the problem up at retro and talking about it with the whole team.

At this point you're looking for one or two problems that have been bugging one of your new teammates for a while, and that have relatively simple solutions. You're looking for something you can put on the retro board and know you won't be the only person who's bothered by that problem. Then, during the team conversation about the problem, you'll identify something that teammate suggests as an action item that we could try immediately. That way the team starts to see you as someone who helps them solve their problems.

The feeling that you want to create, the association you want people to have with you, is, "Oh, so-and-so joined the team and little things started to get better, almost immediately. It feels like we're starting to make some progress. And it's not like they showed up and started telling me what to do, either. They're really listening to me, they're helping me explain myself to the rest of the team."

Pretty soon, you'll start to get into the really sticky issues. The problems the team knows about but is afraid of dealing with. The things that aren't "that bad," but that no one wants to talk about. Maybe they're missing the technical skills to deal with the problem. Maybe there's a knotty people problem at the center of it.

At this point you're going to be talking to you're manager. you're going to bring them that list you've been working on, and you're going to say something like, "Now that you've been on the team for a few weeks, this is what you're seeing. We're making progress on some of it, but some of these seem like they're going to take longer. You wanted to get their thoughts before you try to do anything about them. Is there something you're missing? Is there a particular area they'd like you to focus?"

The reaction you're looking for from your manager, at this point, is something like, "Wow. This is really validating. You've been concerned about these things but the team doesn't seem really bothered by them, so you didn't want to push too hard. They're glad you're bringing this up."

Then we can have a conversation about what their concerns and problems are. You can do some reflective listening to help them organize their thoughts, and you can talk about what you've seen work well, or not, in the past. They'll start to see you as someone with good judgment, and someone they can come to for help solving their harder problems.

There's a very specific reputation you want to have on a team: "So-and-so helps me solve my problems. So-and-so gets things I care about done." That's the reputation that's going to get you the results you want in next year's performance review. That's the reputation that's going to get you a referral a few years from now.

Before you started keeping this kind of list, you brought up problems you saw immediately, as soon as you noticed it. The reputation you got was, "So-and-so is always complaining about things. So-and-so thinks we're never doing things right." People stopped listening to you. You were personally frustrated, and professionally ineffective.

There's no faster way to totally sink my credibility, as a new team member, by making a huge fuss over something that's not a problem, or that the team doesn't see as a problem, or that there's already an effort to fix, or that there's a really simple way to fix that you just didn't see at first. There are always so many problems on a team, so many things that could be better, that you're only ever going to solve a handful of them. Working on problems in the order you noticed them is rarely the most effective order. So the "WTF Notebook" gives you a place to park the impulse to fix it now, damn it! until you have more context for deciding what to work on first.

Instead, for two weeks, you just write things down.

Use Cases

  • Use a "WTF Notebook" to help build a reputation as someone who's really effective at getting stuff done and avoid being someone who's complaining all the time.
  • Use a "WTF Notebook" to help avoid being someone who's complaining all the time.

References