John Cutler’s Post

View profile for John Cutler, graphic

Product Stuff @Dotwork ex-{Company Name}

Experiment WITH not ON... Over the years, I have encountered many process experiments. Sometimes I have been the one doing the experimenting, but most of the time I (and my team) have been the test subject. Someone (often more senior, but not always) has an idea about how to improve something. And that something involves my team. Being in the thick of that dynamic can be difficult. It can be hard to tell what is really happening. At times, it can feel like you are being experimented ON. In my coaching calls, I observe this dynamic with the benefit of some emotional distance. Someone is planning an experiment, or is in the midst of an experiment. Someone is grappling with a coworker's experiment. Or both. Most of the time, it isn't called an experiment. Rather, it's the new process or new way we're doing things. In these calls, I've noticed a common pattern. First, the Why is missing, unclear, or lacks focus. And second, the people involved are not invited as co-experimenters. There's a huge difference between: OK. So here is the new OKR process. OKRs are a best practice, and management thinks they'll be a good idea. and In yesterday's workshop, we decided to try [specific experiment] to address [some longer term opportunity, observation, or problem]. We described the positive signals that would signal progress. They include [positive signals]. We described some signals to watch out for. We agreed that if anyone observes [leading indicators of something harmful or ineffective], they should bring that up immediately. We agreed to try this experiment first over [other options] because [reasons for not picking those options]. Those were good options, and we may revisit them in the future. We may very well experience [challenges] in the short term. Let's make sure we support each other by [tactics to support each other]. In a quarter, we'll decide whether to pivot or proceed. If we proceed, we'll work on operationalizing this, but that is not a given. As we try this, consider opportunities for future improvements. The difference is stark. Yes, the second approach takes longer (at first, and maybe not, see below). Yes, it is more involved and messy. But let's face it: no one likes being the subject of random experiments. The first option is fragile. The second option is powerful and resilient.

Jon W.

Product Owner @ Husqvarna Group | Certified Software Architect

1h

👀 seen this all to many times during the years ♻️ #Why is lacking expected #outcomes is lacking , #involvement lacking or to late to funneled … 🎯🤷🏼🤷🏻♀️ in some cases the #competence regarding the ”test area ” and or #method is also lacking 📖 🙈 Just #execute #mindset with an #output …not on good outcomes

  • No alternative text description for this image
Matthias Patzak

ex-CTO | Author | AWS | Speaker | Advisor | ex-Scout24 | You can't light a fire without a spark.

57m

And the second option is setup as an A/B test with some teams using the new and some the old process

Like
Reply
Idan Melamed

Senior Engineer | Ex-Head of DevOps | Mob programming | Published translator on Non-Violent Communication

4h
See more comments

To view or add a comment, sign in

Explore topics