Solve the Right Problem at the Right Level
This is one of the common principles that not only software developers are adhering to, but also the whole of civilization is attempting to adhere to. But it is sometimes not as easy as it may sound to figure out the right problem, and, more importantly, what is the right level.
A simple example is a pull request fixing a small bug that should not be blocked because of an architectural decision made a year ago and has about 5 engineer years’ worth of work built around it. The right problems for a bugfix PR include the basic sanity checks like: does it fix the symptom or fix the root cause? Does it follow proper coding principles? And so on. That is pretty straightforward to know. Anything that is related to fixing this bug is the scope that needs to be addressed by this PR.
One step further from this is an architectural decision in the form of an ADR. The discussion around it and the changes that could be included in the ADR are scoped to this project within the overall product goal. In an ADR conversation, the problem to address is this architectural decision for this product. not the enterprise’s tech strategy. Again, straightforward and simple.
A few steps away from technology matters are people, personnel, as well as cultural matters. Imagine a new platform adoption for an enterprise, a new way of working for the enterprise, or anything that impacts a larger audience over time. What is the right level to address that? Is it the highest executive in charge of the eventual audience that should send down a mandate with a booklet of new ways of working everyone should read adhere to? This is likely to backfire, be ignored, or misinterpreted in many different ways by different recipients (unless it is extremely detailed and covers nuances, which will result in a countless number of pages that very few will read).
Addressing the right problem at the right level can sometimes be the outcome of a different scoping approach. Of course, it is a company-wide problem to solve, but it can be bootstrapped from a much smaller scope and level. For example, addressing the transitions I mentioned above, at the executive level is not going to result in an organization being transformed overnight, over a year, or in any reasonable span of time, unless such executives take drastic (unhealthy) measures. but using a combined solution of having a kernel team/department take on and accept the transformation and slowly and organically grow the transformation toward adjacent departments or teams can result in an accelerated transformation of adaption of a new platform or way of working.