-
A conversation with @laiamart this morning talking about the complexity of designing new features take more time overtime, it made me thinking about perceived "#technicaldebt" and #complexity in a product lifetime Let's use this common grid to evaluate if a feature is worth 1/8
-
As developers, we tend to justify that we are going slower because of an accumulated technical debt. It might be related but it's an oversimplification of the situation at hand. 4/8
-
👉 You no longer have the quick-win features 👉 The product complexity increases, and the architecture to support it as well 👉 The mental model is bigger and it causes an increased cognitive load to handle the product domain 5/8
-
You are not slower, you are facing the essential complexity of the problem space you aim to solve. In this scenario, we used to start growing the teams and break the solution into different domains, so that we decrease the team cognitive load to maintain delivery velocity 6/8
-
In the current scenario where growing the teams isn't as common as before, we need to adapt our practices, methodologies and expectations to the new context. An example can be an increased cycle and lead time. 7/8
-
You build a lot of features already that provides great insights about your customers and business. Use that organizational knowledge to design effective product delivery processes to deliver the right thing. You need to experiment with novel practices here! 8/8
-
Our tool of managing higher cognitive load has been building new teams for several years. Without this option, we are exposed to an uncharted space that we need to learn how to manage this situations with the tools and context at hand. We all are learning here 😄 bonus 9/8