Thinking in the era of frameworks

This week’s briefer:

• Enough Leadership, time for communityship

• What Slows Us Down

• Leah & Teresa Torres & Hope Gurion: Moving orgs and teams from output to outcome

There was one time in my career where a manager came to the team and said: “let’s change the team’s framework”. Before this, I had many conversations with them about what, I felt, was needed to improve the team, how to deal with the complexity of the application. In essence, how to deliver more frequently and with more quality, so we could meet business and customer outcomes.

The framework focused on delivery, and gave a process around projects and how to build them faster. The reality is that you could’ve change this process with any other that only focuses on building stuff and nothing would’ve changed.

Frameworks are seen as the miraculous answer to any problem. Because the process or the tooling is what’s perceived to be broken. And if it's a delivery framework which promises to revolutionize engineers' productivity without actually changing incentives, habits, the system, how we organize or without reflecting on their roles, you have a winner.

If we look at the product side, we also see plenty of frameworks or methodologies, and product managers that go for them in a heart beat, believing that they will solve their issues, and can get confused if there are different methodologies that tackle the same problem.

Typically, when we grab a methodology or framework straightaway, we're suppressing our thinking and going immediately for a solution. It's like when you go to a doctor, your cholesterol is high, and they just get you pills to lower it down, without looking deeper. We've chosen the framework as an easy fix, a recipe.

A methodology can be good, don't get me wrong, but more important than the tool or process are the why, the underlying concepts and principles and the habits that you're doing. A process can give you a useful scaffolding at the beginning, if you don't have much knowledge, experience or are learning, but the goal is to be free from it by building a more profound understanding of why you're doing what you're doing. Following a process blindly, forever, or jumping to another, with no understanding, is foolish.

A common scenario is that we believe that the methodology or the way we work is the truth, that there's nothing outside of it, and even more worrisome, we refuse to believe there can be anything better. The collective version of agile is a perfect example of this. How many teams swear by it? If I had a penny for all the times I've heard the words “refinement”, “planning”, “stories”, “story points”, “stand-ups”… I'd be a millionaire by now. The interesting thing is that the same people that use those words and processes don’t understand why we would want to do that or not, what the underlying concepts are and just follow it or impose it blindly. A collective delusion.

As an example, in my journey to learn about product management, I read a few books. One of them was Continuous Discovery Habits by Teresa Torres. To me, it’s a wonderful and practical book about how to do discovery as a team, and I wish teams could take inspiration from it. What I observed after reading more books about product management and my own experience is not that Teresa’s approach is the ultimate truth, but that the concepts, principles and habits she describes—and others do as well—are what matters the most. From those concepts we can adapt and find our own ways, that might be different from or similar to the specific approach of the book, but we would be in the right track.

If your first solution to your problem is to immediately change the framework, stop and think, look deeper, ask yourself what it is that you’re trying to achieve, refer to the principles, concepts, habits.

What happened with the change of framework that the manager wanted? It went through and no real change happened, as expected, the only change was that developers were more frustrated. The change was focused on how to get us to build faster through process, but ignored everything else.