Happy Friday!

Yesterday, I went and split my beehives. This was actually the first time I did this, so while the process seemed normal, it was a little challenging since it was my first time.

To prepare for this, I re-read some old material and looked up a ton of new material from beekeepers in the industry I respect. They each had their own way of doing things, and none of them was a perfect match for my situation.

To make it even more tricky, I split my hives using a piece of equipment that isn't commonly discussed, which means there is even less material to prepare with.

If you want to see a short video of me out there splitting the bees you can look here. I think it's like 6 minutes long.

Why am I talking about bees? Well, having to split the bees is very much like something I see all the time when I work with clients, which I'm going to call the model paradox.

For me, as a consultant, it's really beneficial when I can explain things to folks as a series of steps, a model, or a framework. When I can say that I have a 3-step approach or use some model for team dynamics. It's beneficial because the other version of saying, "It depends" doesn't really instill much confidence.

So why the paradox? We need models, recipes, and frameworks to understand situations and how to tackle future problems. At the same time, no recipe, model, or framework is perfect for the situation. To say I won't use one because it's imperfect erodes confidence in my ability, but to say I'll use one diminishes the reality of how much I'll have to adjust to the situation.

Splitting my bees was a perfect example of this. Plenty of folks explained approaches to splitting bees, but my situation was different enough that I had to go off-script.

Many clients are like my bees—just unique enough that a textbook approach won't quite work.

The hard part about this little problem isn't that we have to go off script. It's knowing where and how to do so.

An example that I think a lot of teams and companies are familiar with is when they try to become agile and adopt Scrum. Many companies go off script with Scrum and do their best with it, but often, there are lackluster results.

Then I showed up, and the teams were still doing Scrum, but objectively and subjectively, things were a lot better. I get the questions, "What did you do?" or, "How did you do that?" because there aren't many obvious differences between before and after, but things are better.

The difference is in my understanding of where to go off-script and where not to.

And I'll tell you a secret here: I only learned how to discern these things through experimentation. Going off-script is fine when you realize you don't know if you will get it right, assess what is going on, and adjust. Going off-script because you think you solved the problem is often not going to work out optimally.

Am I experimenting with my bees? You bet. My experiment will end in 1 month when I find out if they can raise new queens in the newly split hives. If they can't, I'll purchase new queens and keep going.

Sincerely,

Ryan