3X but It's People

Kent Beck’s “3X” model is an interesting way to think about software work over the life of a product. Read the article and watch this video for a catch-up.

My high-level paraphrasing is that every “project” goes through three phases, in order:

• Explore - you’re experimenting with solutions, including choosing the problems to solve, trying to find a good fit
• Expand - you found a problem/solution fit, it working well enough that everyone wants it and you’re scrambling to scale it
• Extract - you have scaled, now you need to take a deep breath and extract all the value you can from it

Lather, Rinse, repeat.

I put projects in quotes because the model scales from a work ticket all the way up to a startup business. As Kent says, it’s fractal - 3Xs all the way down. Pick your altitude(s) when applying to your own context.

3X is Made of People

I’ve been thinking about the 3Xs from a different direction. What does 3X look like when looking at it people-first? Who are the people who thrive, or don’t, at each stage? Hypotheses ahead…

Have you worked with people who seem to hop from startup to startup? How about folks who thrive on the chaos of sudden success? Ever seen people who drop into any protect and tidy up all the time, making things simpler and smoother every day?

Using 3X as a guide, what you have seen are Explorers, Expanders, and Extractors. They are people who are really good at contributing at each stage. And maybe less so in others. They show up in all roles on software product teams. How does this idea change your thinking about the people on the project?

I once worked with a developer I liked a lot named Freddie. I learned lots of great coding techniques and deep domain knowledge from him. We got so much done when Freddie was on a project. But I did notice a pattern. When he stayed on a project for a long time, new people had a hard time ramping up to the patterns in the code. Freddie would keep getting lots done, but the team as a whole would slow down. This didn’t make sense.

Freddie was an Expander. He was great at dropping in to a project with a lot of chaos, taming the really hard, immediate problems while ignoring the things that didn’t matter as much. He loved the variety and the urgency. He helped teams get out of the panic and closer to Extract territory. But when the project crossed over into the Extract phase, he wasn’t as effective. His solutions worked, but were hard to learn about and to maintain day-to-day.

Once management realized that he had a sweet spot, we shifted his role and moved him between projects often. More teams got “Freddie Time” when they had scaling issues. He stayed engaged and helpful on each project, teaching his Expander skills all around the department. Everyone was happier.

Explorers are the folks who excel at starting new projects. They deal with bootstrap and boilerplate to get the team moving, help set architectural direction, and encourage experimentation with new tools and techniques. All of this works well when the greenfield is new and lush. But they it doesn’t work as well when scaling challenges start - that’s when you need a Freddie.

Extractors are the ones who want to know everything before they get started helping a team. Sort of like Marie Kondo. They want to march through big swaths of the code, looking at patterns and tools. They delete the unnecessary complexity with extreme prejudice. They spot all the opportunities to refactor, encourage test suite maintenance, and make the project simpler.

(I am full of Extractor tendencies when it comes to software projects. That doesn’t hold true in the real world. Do not look in my garage.)

What, Then?

Every team needs Explorers, Expanders, and Extractors. They are each handy in their own ways and at key times. So how can you apply this new perspective?

If you don’t manage people, maybe this model can help you understand yourself a little better. You used to love your project, but it now seems like a slog. Or your performance feedback went from very positive to meh. Perhaps your project has moved between stages and needs you to change your mindset. Or maybe there’s another project when you can help even more.

If you do manage people, take a look at your teams and their projects. What stage of 3X are they in? Are they suddenly struggling? Or are they dealing with change very well? How are the people on those teams faring on the projects over time? Will some coaching about what the priorities need to be help them? By moving people between projects, can you help a career and a project (and thus a business) at the same time?

Thinking about the 3X’s of people can help you staff your projects for maximum productivity and happiness. It turns out software is made of people.