Why Only Change Frames?

This entry is part 3 of 3 in the series Changing The Frame

Today I want to answer a question that, honestly, almost no one ever asks. Why are we changing frames, instead of getting rid of them altogether? Talking about change in the geek trades is a joy for me, but I’m even more interested in seeing change out in the world. Please think outside the monitor. Black Lives Matter. Why are we only changing frames, and not breaking them, destroying them, ridding ourselves of them? First, lemme answer the question. Then, […]

Why Only Change Frames? See Full Post

The Frame-Changing Triad

This entry is part 2 of 3 in the series Changing The Frame

We started with the concept of the mental frame, a comparatively rigid & invisible construct which structures and guides nearly all our behaviors. Today, let’s take up the triad of powerful forces that we can use to change frames: community, narrative, and experience. https://www.geepawhill.org/2023/01/20/changing-the-frame/ As ever with me, though considering change in the geek trades is a pleasure, it is not the main story. I remind you that we need change-in-the-world at least as much as we do change-in-the-code or

The Frame-Changing Triad See Full Post

Slowing Decisions Down

This entry is part 5 of 5 in the series Leading Technical Change

Here’s another technique card from my seminar, “Leading Technical Change”. We first get into midwifing change precisely because we want it to be smoother, easier, and faster. But sometimes, a coach needs not to rush a decision through, but to slow it down. It’s so exciting when our proposed change starts to catch fire, especially when major influencers in our team suddenly “get it”, and want the whole team doing it. “Winning.” And it is winning. But when you start

Slowing Decisions Down See Full Post

What About Failure?

This entry is part 4 of 5 in the series Leading Technical Change

If we’re going to enable and support change, we’re going to fail, more often than we succeed, and we want to bake that idea in, early on, lest we fail both more often, and potentially more disastrously. Here’s some thoughts around this NOT DEPRESSING topic. 🙂 The weirdest thing about all this: it’s actually rather hard to tell when you’ve failed vs succeeded, working as midwife to change. I’ve had what I thought were successes backfire horribly, inadvertently leading teams

What About Failure? See Full Post

Can We Be Honest?

This entry is part 3 of 5 in the series Leading Technical Change

Can we be honest? If we’re going to be successful change midwives, honesty is very important. In this technique card from Leading Technical Change, I talk about some of the ins & outs of this complicated topic. The first point is urgent: Being honest means believing everything you say, not saying everything you believe. Honesty is really important, but people quite often over-share in the name of pursuing honesty. Every healthy person, for instance, has moments of extreme negativity. Our

Can We Be Honest? See Full Post

Detail: Not The Long Game

I was gratified by the response to my first "detail" article. But I did note that many persons praised my article for its commitment to the long game. Framing the commitment, for a geek, to detail, as a long game, seems right, sounds right, cuz after all, we only ever care about quality in the long game. And this is why y’all can’t convince anyone to do this or think this or feel this. When does a bad variable name

Detail: Not The Long Game See Full Post

Slash the Load

This entry is part 2 of 5 in the series Leading Technical Change

The people who hire me ask me to help their teams make changes. Most of the time, my first step is to see how I can slash those teams’ load. Here’s a technique card from my seminar, “Leading Technical Change” Raw text of a technique card: Wait, what? First thing I do To me, this is dreadfully obvious, but for a lot of folks seeking change, it comes as a completely shocking idea. The weirdest part, though, is that it

Slash the Load See Full Post

Detail: Series Intro

Detail: The thing that strikes me over and over again, in my own work style, in my Friday group’s analytics, in Ron’s long-running Kotlin and short-running Gilded Rose series, is how much attention high-skill geeks pay to some of the smallest details in the code. An example. I was doing Gilded Rose the other day, first time in years, and we start with the ugly method, which we’re asked to add a feature to, following certain constraint rules to make

Detail: Series Intro See Full Post

Joy Project: FGNO Plotter

Joy project: Today’s a comparatively light work day, so I’m gonna lay out what I’m actually trying to do with this project. The source, btw, is at: GitHub – GeePawHill/fgno-plotter Playtime project for the fgno meetup. Contribute to GeePawHill/fgno-plotter development by creating an account on GitHub. Feel free to poke around. There are a bunch of simultaneous missions going on with fgno-plotter, which is why it’s a joy and learning project. "fgno", btw, is an abbreviation of "Friday Geek’s Night

Joy Project: FGNO Plotter See Full Post

Scroll to Top