Are you thinking transformation? That’s what I was told again recently: we want to transform ourselves and have a product approach. I hear it often. It’s normal. It’s my job. I’m going to say it again, a little differently, a little as usual, what I believe in, my experience. It’s probably part of my role: repeat, remind, repeat. This time I quickly made 27 sentences / slides. Sentences on which I bring context and content. If you want to talk about it with me, let me know: I’m not tired of it, repeating yourself is normal, I only bring 50% of the answers, the other part is in your hands. Here are 28 sentences / slides about transformations:

1. Organizations whose transformations succeed don’t talk about transformation, but about what they succeed at by having transformed themselves.

2. You say “transformation”. I understand that you are at the foot of a potential culture change, because we are constantly transforming.

3. This culture change, these “transformations”, often come from the need to evolve well in a complex world.

4. To succeed in a complex world: autonomy with clear rules, a clear objective, feedback (among others).

5. Autonomy is not autarky, nor absence of accountability.

6. Autonomy generates engagement.

7. The complex world constantly evolves. To adapt to it and secure ourselves (and allow autonomy) we work on small pieces.

8. For this to be effective: we build small finished things, which carry meaning. This implies an often different organization that can achieve this.

9. If we’re capable of breaking down small pieces that carry meaning, we might as well deliver them prioritized by value.

10. Delivering things piece by piece, we go fast, prioritize by value: we measure the impact of our hypotheses, we continue, we stop, we adapt. That’s the promise of agility. In any case, that of the product approach.

11. You could have another benefit: if you give autonomy, a clear framework, clear rules, feedback, and this work by small elements: you make your organization more resilient and flexible.

12. The difficulty for management: letting go of the how, micromanagement, and knowing how to create a framework, a direction.

13. The difficulty for the business teams: knowing how to break down, knowing how to build piece by piece with a vision: like a termite mound.

14. The difficulty for technical teams: flow and automation (particularly testing).

15. The difficulty for everyone: being value-oriented, measurements are oriented towards impact, the value delivered.

16. Scaling requires a synchronization effort (quarterly planning, etc.) and a common vision (who thinks about the whole, defining a “cathedral”).

17. Scaling requires a capacity to break down teams and the product that minimizes dependencies as much as possible, but allows delivering finished things with value.

18. Scaling without damaging autonomy too much: component teams become feature teams, then become impact teams.

19. In scaling, the illusion of the absence of physical constraints is dangerous: maximum team size, dependencies (again), maximum number of people in a conversation, maximum number of teams in parallel around a close subject, etc.

20. Scaling will require a modularization of the technical layer to help minimize dependencies and strengthen autonomy.

21. Scaling will raise questions about the transformation pattern: “by apartment”, in “big bang”?

22. A transformation: you must suspend your beliefs. Do experiments, experience things.

23. A transformation: don’t apply cookbook recipes or false pretenses.

24. “People copy the most visible, obvious, and frequently least important practices” (Pfeffer & Sutton, Three myths of management 2006)

25. First look: Is it a political company or one that carries meaning? A transformation for what? Are we talking about value?

26. First look: Where are decisions made?

27. First look: Finally, are we thinking about the whole?

Thank you